FHEM Forum

Verschiedenes => Bastelecke => Thema gestartet von: Telekatz am 09 November 2016, 20:29:52

Titel: Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 09 November 2016, 20:29:52
Hallo zusammen,

Ich möchte euch ein neues CUL Interface vorstellen. Einen CUN zum selberbauen.
Benötigt werden dazu folgende Teile:

Maple Mini Board:
https://de.aliexpress.com/item/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/32214664071.html (https://de.aliexpress.com/item/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/32214664071.html)

W5100 Ethernet Modul:
https://de.aliexpress.com/item/Free-shipping-W5100-Ethernet-module-Ethernet-network-module-for-arduino/32341522510.html (https://de.aliexpress.com/item/Free-shipping-W5100-Ethernet-module-Ethernet-network-module-for-arduino/32341522510.html)

CC1101 Funkmodul
https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32635393463.html
(https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32635393463.html)

Die Module werden gemäß Schaltplan miteinander verbunden. Da alle Module mit 3,3V laufen sind keine Bauteile für eine Pegelanpassung notwendig.

Zum flashen des Maple Bootloaders wird noch ein USB/TTL Wandler benötigt. Da der UART1 Anschluss des Controllers 5V tolerant ist kann auch ein Wandler mit 5V Ausgang verwendet werden. Angeschlossen wird der Wandler an X4 (DBG).

Die Firmware ist in der a-culfw (https://github.com/heliflieger/a-culfw) enthalten. Es gib zwei Versionen, einmal für ein W5100 und einmal für ein W5500 Ethernet Modul. Falls kein Ethernet Modul vorhanden ist (MapleCUL), ist es egal welche der beiden Versionen verwendet wird.
Die Binarys gibt es hier (https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw) zu herunterladen.

Flashanleitung: https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md)

Wiki Artikel: MapleCUN (https://wiki.fhem.de/wiki/MapleCUN)


Update 17.12.2016:
Schaltplan geändert

Update 05.02.2017:
Schaltplan geändert
Wiki hinzu

Update 06.03.2017:
Flashanleitung verlinkt
Titel: Antw:Selbstbau CUN
Beitrag von: locutus am 10 November 2016, 23:17:39
Würdest du bitte den Quellcode veröffentlichen bzw. verlinken? Danke im Voraus!
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 11 November 2016, 08:01:13
Der Quellcode ist im Branch STM32 der a-culfw verfügbar:
https://github.com/heliflieger/a-culfw/tree/STM32 (https://github.com/heliflieger/a-culfw/tree/STM32)
Titel: Antw:Selbstbau CUN
Beitrag von: locutus am 26 November 2016, 12:55:17
12 € für ein CUL mit 128 kB Speicher und Netzwerkanbindung! Das Preis-/Leistungsverhältnis ist unschlagbar.
Ich habe noch einige Fragen zum selbstbau CUN.

CUL Kommando "L" ...
#define HAS_MAICO
Was für ein Funkprotokoll ist das?

Stellt
#define HAS_UART 1
CUL RAW Messages transparent auf USART1 bereit?

Zusätzliche CC1101 Transceiver ...
//additional CC1101 Transceiver
//#define CC1100_ASKSIN 1
//#define CC1100_MORITZ 2
//#define CC1100_MAICO 3

Ist das nur graue Theorie oder bereits in der Praxis anwendbar?

Ist WIZnet W5100 durch W5500 ersetzbar?
#define HAS_W5500
W5500 ist im Quellcode vorhanden, aber wird die Hardware tatsächlich unterstütz?

Die Konfiguration (http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten) und Anbindung an FHEM klappt, aber der Router und die Netzwerkscanner App zeigen die IP-Adresse des mapleCUN nicht an. Ist das so gewollt oder liegt es möglicherweise an der FritzBox?

Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 26 November 2016, 23:50:06
Zitat von: locutus am 26 November 2016, 12:55:17
CUL Kommando "L" ...
#define HAS_MAICO
Was für ein Funkprotokoll ist das?
Das ist für meinen Maico Lüfter http://www.maico-ventilatoren.com/produkte/produkte-maico/katalog/detail///p37601/ (http://www.maico-ventilatoren.com/produkte/produkte-maico/katalog/detail///p37601/).

Zitat von: locutus am 26 November 2016, 12:55:17
Stellt
#define HAS_UART 1
CUL RAW Messages transparent auf USART1 bereit?
Das ist noch ein Überbleibsel aus der Cube Vorlage. Hat momentan keine Funktion. Angedacht hab ich aber eine Funktion wie beim CUNx mit dem Pigator. USART 2 und 3 des STM32 sollen über zusätzliche USB Ports und/oder Netzwerkports direkt angesprochen werden können. Einen HM-MOD-RPI-PCB könnte man dadurch Netzwerkfähig machen.

Zitat von: locutus am 26 November 2016, 12:55:17
Zusätzliche CC1101 Transceiver ...
//additional CC1101 Transceiver
//#define CC1100_ASKSIN 1
//#define CC1100_MORITZ 2
//#define CC1100_MAICO 3

Ist das nur graue Theorie oder bereits in der Praxis anwendbar?
Es funktioniert auf meinem Cube. Die Kombination SlowRF/Homematic funktioniert dort ohne Probleme. Für den STM32 muss ich das erst noch anpassen.

Zitat von: locutus am 26 November 2016, 12:55:17
Ist WIZnet W5100 durch W5500 ersetzbar?
#define HAS_W5500
W5500 ist im Quellcode vorhanden, aber wird die Hardware tatsächlich unterstütz?
Die Basis für den Netzwerkzugriff habe ich vom CUNx übernommen. Dort habe ich den W5500 durch den W5100 ersetzt. Sollte also mit Anpassungen auch wieder mit dem W5500 funktionieren. Zum Testen habe ich aber nur den W5100.

Zitat von: locutus am 26 November 2016, 12:55:17
Die Konfiguration (http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten) und Anbindung an FHEM klappt, aber der Router und die Netzwerkscanner App zeigen die IP-Adresse des mapleCUN nicht an. Ist das so gewollt oder liegt es möglicherweise an der FritzBox?
Gewollt ist das nicht. Liegt dann aber wohl eher an der Implementierung in der Wiznet Lib oder im W5100.

Der Quellcode wurde jetzt übrigens auch in den Master Branch der a-culfw übernommen.

Titel: Antw:Selbstbau CUN
Beitrag von: locutus am 27 November 2016, 11:00:42
Mir fällt auf, dass MAICO
#ifdef HAS_MAICO
{ 'L', maico_func },
#endif

mit BELFOX kollidiert ...
#ifdef HAS_BELFOX
{ 'L', send_belfox },
#endif


Das Kommando "L" ist bis heute in Commandref (http://culfw.de/commandref.html) nicht dokumentiert.
Auch das willkürliche Flackern bzw. Aufleuchten der CUL-LED ist vermutlich darauf zurückzuführen.
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 27 November 2016, 14:02:40
Das Flackern der LED kann damit nichts zu tun haben.

Es wir zwar bei beiden Protokollen "L" verwendet, aber
#ifdef HAS_BELFOX
{ 'L', send_belfox },
#endif
ist in der fntab[] der ARM Devices nicht vorhanden. Und nur diese Devices haben Maico. Desweiteren hätte das auch nur Auswirkungen beim Senden.

Das flackern liegt an der Empfindlichkeit des CC1101, der Rauschen im slowRF Mode empfängt. In rf_receive.c wird dann versucht das zu decodieren. Das löst dann das toggeln der LED aus.
Abhilfe schafft da, die Empfindlichkeit des CC1101 herunterzusetzen.
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 06 Dezember 2016, 11:03:08
Hi Telekatz,

nochmals danke für den Tip mit dem Maple Mini.
Hab mich jetzt schonmal soweit eingelesen.
Will den Maple als CUL verwenden.

Wei ich gesehen habe muss der Maple mit USB TTL adapter geflasht werden.
Da ich bisher nur die arduinos per USB geflasht habe und den Bootloader der Arduinos per zweitem Arduino im ISP mode habe ich eine kurze Frage.
Ist dieser USB to TTL ok?
http://www.ebay.de/itm/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-Arduino-Mini-Port-/222099549821?hash=item33b62a2e7d:g:ipAAAOSwd0BVxNxc

Danke und Gruß,
Stefan
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 06 Dezember 2016, 11:43:28
Zitat von: stefanru am 06 Dezember 2016, 11:03:08
Wei ich gesehen habe muss der Maple mit USB TTL adapter geflasht werden.
Da ich bisher nur die arduinos per USB geflasht habe und den Bootloader der Arduinos per zweitem Arduino im ISP mode habe ich eine kurze Frage.
Ist dieser USB to TTL ok?
http://www.ebay.de/itm/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-Arduino-Mini-Port-/222099549821?hash=item33b62a2e7d:g:ipAAAOSwd0BVxNxc
Ja, mit dem sollte es funktionieren.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 17 Dezember 2016, 17:15:14
Danke für das geniale Projekt !
Die Teile sind vorher gekommen, also kanns nun losgehen !


Bin am überlegen ob ich dazu eine Platine pinseln soll... (Das wäre schlauer gewesen mit der Teilebestellung zusammen)

Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 17 Dezember 2016, 20:19:37
Mittlerweile funktioniert auch der Zugriff auf die beiden freien seriellen Schnittstellen. Über USB werden dabei zwei weitere Schnittstellen angelegt, der Netzwerkzugriff erfolgt über die Ports 2324 und 2325.

Zur Einstellung der Baudrate über Netzwerk gibt es folgende Befehle:

UART0 Baudrate einstellen
pb0@115200

UART1 Baudrate einstellen
pb1@9600

Baudrate im EEPROM speichern
ps

Baudrate anzeigen
pi


Ein am UART0 angeschlossener HM-MOD-UART kann z.B. mit folgender Definition in FHEM eingebunden werden:
define myRemoteHmUART HMUARTLGW uart://192.168.42.23:2324

Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 18 Dezember 2016, 11:10:15
Ich hätte noch 1-2 Fragen zum Thema:

Der CC1101 braucht Platz von ca 8 Pinreihen des Maple. Wenn man also eine Platine machen möchte die nicht größer als der Maple ist, und keine genutzen Pins unter dem CC1101 sein sollen (wäre notfalls auch möglich), dann sind Pins im Weg.
Könnte 11+10 (Nummer laut Aufdruck) weiter nach unten auf andere Pins (weg von der USB Buchse) verlagert werden ?

Mein favorisierter Weg:
Flashen sollte doch auch per USB über den Bootloader möglich sein, dann wäre 21+22 unnötig, und man könnte einfach eine Platine machen die etwas breiter ist und ca. Nr. 15-24 überdeckt (10 Pins sind mehr als genug!) ?
Frage dazu: wäre es möglich das Makefile so anzupassen dass auch ein Binary passend für Bootloader-Einsatz erzeugt werden kann ?
Titel: Antw:Selbstbau CUN
Beitrag von: locutus am 18 Dezember 2016, 13:45:37
Nimm bitte Rücksicht auf diejenigen, die den MapleCUL/MalpeCUN schon im Einsatz haben. Ich halte nachträgliche Änderungen an der GPIO-Belegung im Quellcode und somit Änderungen an der Referenzschaltung für problematisch. Denn nicht jeder ist dazu in der Lage, den Code zu deuten und verstehen zu können.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 18 Dezember 2016, 15:33:09
ZitatNimm bitte Rücksicht auf diejenigen, die den MapleCUL/MalpeCUN schon im Einsatz haben

Das passt eh zu meiner favorisierten Methode:
Zitatkönnte einfach eine Platine machen die etwas breiter ist und ca. Nr. 15-24 überdeckt

Ich hab nochmals nachgelesen:
ZitatRX1/TX1 am Maple Mini mit einem USB/TTL Adapter mit dem PC verbinden.
Beim STM32F105 kann man direkt per USB Flashen. Habe gehofft das würde hier auch gehen.
Weisst Du ob ich hier falsch liege ? (Das würde zwei zusätzliche PINs bedeuten, was kein Beinbruch sein sollte weil ich eh 10 Pins für Enternet, aber es hat nicht jeden nen USB2Seriell Wandler)

Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 18 Dezember 2016, 15:45:54
Zitat von: ranseyer am 18 Dezember 2016, 11:10:15
Könnte 11+10 (Nummer laut Aufdruck) weiter nach unten auf andere Pins (weg von der USB Buchse) verlagert werden ?
Möglich ist das, aber wie locutus schon bemerkt hat, möchte ich das jetzt nicht mehr an der Referenzschaltung ändern. Du müsstest das dann für dich selber kompilieren.
Wenn du die Belegung änderst, sollte CC_IN0 auf 3 (PB0) umgelegt werden. Ansonsten müsste auch noch der EXTI IRQ Handler angepasst werden.

Zitat von: ranseyer am 18 Dezember 2016, 11:10:15
Mein favorisierter Weg:
Flashen sollte doch auch per USB über den Bootloader möglich sein, dann wäre 21+22 unnötig, und man könnte einfach eine Platine machen die etwas breiter ist und ca. Nr. 15-24 überdeckt (10 Pins sind mehr als genug!) ?
Frage dazu: wäre es möglich das Makefile so anzupassen dass auch ein Binary passend für Bootloader-Einsatz erzeugt werden kann ?
Der integrierte Bootloader kann nicht über USB flashen. Für USB bräuchstest du also einen extra Bootloader, den du ja auch irgendwie flashen können musst. Allerdings ist 21+22 dazu gar nicht nötig. Das ist nur die optionale SWD Schnittstelle. Der Bootloader benutzt 25+26.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 18 Dezember 2016, 17:20:33
Naja: Beim Bootloader habe ich mit dem von LEAF-Labs gute Erfahrungen. Allerdings auf den ST-Link nur mühsam zu flashen und funktionierte dort nur mit nem extra Widerstand. Aber wenns mal lief natürlich geschickt.

Zur Platine habe ich nun dass Problem dass diese 51mm lang wird. Somit würde diese teuerer.
Folge Optionen sehe ich:
-Größer machen und den Nutzen mit anderem auffüllen (ungern)
-murksen und dem Fertiger die letzte Toleranz nehmen und "passt schon" hoffen
-die erste oder letze Reihe weglassen (Also AV+; Frage: Wäre es möglich die 3,3V für den CC1101 auch an einem anderen PIN (12-14,8,9) zu gewinnen, das sollte andere die die Schaltung schon haben ja nicht stören)

Was meint Ihr ?
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 18 Dezember 2016, 17:29:14
Wenn es kein CUN werden soll, kannst du die letzte Reihe (31+VIN) weglassen.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 18 Dezember 2016, 18:38:41
Das ist klar. Aber um flexibel zu bleiben mach ich das nicht.
(Meine Frage war ob an dem STM32 an einem der programmierbaren Pins 3,3V "programmiert" werden könnten und ob der Ausgang auch genug Strom für das CC1101 liefert. Aber selbst wenn es gehen sollte. scheint mir das etwas riskant)
Ich glaube ich schneide das Board einfach etwas extremer ab. 
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 19 Dezember 2016, 13:28:08
Flashen direkt per USB geht bei meinem MAPLE-Mini !
Zitat#! /bin/sh
while (true); do
sudo dfu-util -d 1eaf:0003 -a 1 -D ./MapleCUL.bin
if [ $? -eq 0 ]
then break
fi
sleep 1
done
exit

Erst das Skript von oben starten, dann kommen so lange "komische" Meldungen bis der MAPLE angeschlossen wurde. Anschliessend geht es los:
Zitatdfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: No DFU capable USB device available
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download   [=========================] 100%        44764 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

PS: Klar kann ich auch auf anderen Wegen flashen. Mir geht es um den einfachsten Weg.


Zur Platine:
-Bin ich "begrenzt zufrieden mit meinem Stand. Bei meiner Herangehensweise kann die Antenne nur auf der selben Seite wie der Mini-USB Anschluss beim Maple liegen.
-Die Platine hat noch ausreichend Luft für Spielereien: Ich habe mal nen IR-Receiver angedacht, den man normal nicht bestückt, aber dann so für ein anderes Projekt nutzbar sein könnte, Kondensator wegen IR oder... Massefläche fehlt noch wegen Übersichtlichkeit
-ich habe mal den Zwischenstand angehängt, sobald es Sinn macht auch im Git.
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 19 Dezember 2016, 16:45:41
Zitat von: ranseyer am 19 Dezember 2016, 13:28:08
Flashen direkt per USB geht bei meinem MAPLE-Mini !
ES geht, weil ein Maple Mini genauso wie ein Arduino mit einem extra Bootloader ausgeliefert wird. Der STM32F103CBT6 selbst unterstützt kein DFU über USB. Deshalb solltest du auf deinem Board auf jeden Fall noch den DBG Anschluss X4 vorsehen.

Zitat von: ranseyer am 19 Dezember 2016, 13:28:08
-Die Platine hat noch ausreichend Luft für Spielereien: Ich habe mal nen IR-Receiver angedacht, den man normal nicht bestückt, aber dann so für ein anderes Projekt nutzbar sein könnte, Kondensator wegen IR oder... Massefläche fehlt noch wegen Übersichtlichkeit
Ich würde noch einen UART Anschluss für einen HM-MOD-UART empfehlen.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 19 Dezember 2016, 17:58:04
Das wäre dann recht massiv: 4 von 6 Pins genutzt im 2mm Raster: https://forum.fhem.de/index.php/topic,56606.msg481391.html#msg481391 (Denke das wäre der sinnvollste Anschluss)
Was hältst du von Serial1 (RX+TX über Kreuz nehm ich an; mit Serial 2+3 wären dann noch Anschlüsse frei: Analog, Digital und I2C...) ?

Frage wie sinnvoll ist diese Nutzung ? -Wenn recht unwichtig würde ich evtl. nur die 4 nötigen Pins im 2,54mm Raster rauslegen und jeder kann es selbst verbinden. Dupont Kabel für 2,54mm habe ich noch nie für diesen Fall getestet. Möglicherweise lassen diese sich in diesem Fall (Mitte frei) ja trotzdem einstecken. (Denke erst nach etwas feilen)

PS: Ja den X4 und nochmals ca. 5 Pins herausführen hatte ich eh vor. (Oben rechts auf dem Bild)
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 19 Dezember 2016, 19:04:53
Ich denke, es sollte reichen, wenn nur die 4 nötigen Pins auf eine 2,54mm Stiftleise herausgelegt werden.

Serial1 geht schon an den DBG Anschluss X4. Wenn du Serial2 nimmst (PA2+PA3), dann kann man Serial3 (PB10+PB11) noch alternativ für I2C nutzen um einen CUNO zu bauen. 
Titel: Antw:Selbstbau CUN
Beitrag von: bjoernh am 19 Dezember 2016, 20:28:24
Kann man den Maple noch WLAN beibringen? Z.B. mit einem ESP8266 am seriellen Port. Das müsste doch auch gehen...
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 19 Dezember 2016, 22:38:12
Gehen würde das schon. Im CUBe steck diese Funktion ja auch schon drin. Sinnvoller wäre es aber meiner Meinung nach, dem ESP8266 die culfw beizubringen.
Titel: Antw:Selbstbau CUN
Beitrag von: bjoernh am 20 Dezember 2016, 08:50:37
Zitat von: Telekatz am 19 Dezember 2016, 22:38:12
Gehen würde das schon. Im CUBe steck diese Funktion ja auch schon drin. Sinnvoller wäre es aber meiner Meinung nach, dem ESP8266 die culfw beizubringen.
Du meinst also direkt in den ESP8266 die culfw zu implantieren?
Aber wie willst Du dann z.B. den CC1101 ansteuern?
Net wäre das denke ich auf jedenfall, das würde dann ein Miniatur WLAN CUL ;-)
Titel: Antw:Selbstbau CUN
Beitrag von: locutus am 20 Dezember 2016, 09:32:52
Das Vorhaben könnte zur Herkulesaufgabe geraten. Bleibt lieber bei der seriellen Übermittlung der CUL RAW Daten per ESP8266.
https://forum.fhem.de/index.php/topic,56712.0.html
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 20 Dezember 2016, 18:55:14
Habe fertig: https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE


-Erste Version zur Diskussion und sehr gerne zum harten Gegencheck ob die Verbindungen passen
-geroutet mit Freerouting
-wegen der SMA-Buchse frag ich nochmals nen Fachmann zu Layout
-mehr passt kaum noch auf das winzige Board
-die Breite von VCc überdenke ich nochmals, das reduziert extrem die VIAs
-wenn fertig dann kommt noch soweit möglich eine Beschriftung dazu
-eine andere Frage ist welche Gehäuse evtl in Frage kommen (das vom NanoCul dürfte 1-2 mm zu kurz sein), dazu wäre denkbar das ganze noch etwas umzuformen...

Freue mich über Feedback !
Titel: Antw:Selbstbau CUN
Beitrag von: fhem-challenge am 21 Dezember 2016, 11:02:13
Zitat von: Telekatz am 09 November 2016, 20:29:52
Hallo zusammen,

Ich möchte euch ein neues CUL Interface vorstellen. Einen CUN zum selberbauen.
Benötigt werden dazu folgende Teile:

Maple Mini Board:
https://de.aliexpress.com/item/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/32214664071.html (https://de.aliexpress.com/item/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/32214664071.html)
<SNIP>...
Update 17.12.2016:
Schaltplan geändert

Guten Tag,

ggf. dumme Frage von mir: Wie sollte die Integration eines zweiten CC1101 erfolgen (wie im schematic dar gestellt) ? Ist das im "culfw-code" bereits berüchsichtigt ? und erreiche ich den zweiten CC1101 dann mit einem anderen TCP Port (was ja erforderlich wäre) ?

Wenn beides mit "Ja" beantwortet werden kann, wäre das sicherlich ein erfolgreiches Vorhaben. Mit einem zweiten CC1101 (dann ja ggf. eine Mischung aus 868 & 433 MHz) würde man viel erreichen können.

Viele Grüße!

Andreas
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 21 Dezember 2016, 13:21:28
Da es noch experimentell ist, ist im Code berücksichtigt, aber nicht aktiv. Wer das ausprobieren möchte, muss das in der board.h aktivieren und selbst compilieren.
868 und 433 MHz SlowRF gleichzeitig geht momentan auch noch nicht .

Um z.B. SlowRF und MAX gleichzeitig laufen zu lassen, muss folgende Änderung  in der board.h gemacht werden:

//additional CC1101 Transceiver
//#define CC1100_ASKSIN 1
#define CC1100_MORITZ 1
//#define CC1100_MAICO 3


Aktiviert wird der Empfang dann mit:
X21
Zr


Es kommen beide Nachrichtenarten über den gleichen Port. Irgendwann möchte ich es dann noch so umbauen, dass sich die zusätzlichen Transceiver wie ein STACKABLE_CC einbinden lassen.
Titel: Antw:Selbstbau CUN
Beitrag von: fhem-challenge am 21 Dezember 2016, 13:37:47
Zitat von: Telekatz am 21 Dezember 2016, 13:21:28
Da es noch experimentell ist, ist im Code berücksichtigt, aber nicht aktiv. Wer das ausprobieren möchte, muss das in der board.h aktivieren und selbst compilieren.
868 und 433 MHz SlowRF gleichzeitig geht momentan auch noch nicht .

Um z.B. SlowRF und MAX gleichzeitig laufen zu lassen, muss folgende Änderung  in der board.h gemacht werden:

//additional CC1101 Transceiver
//#define CC1100_ASKSIN 1
#define CC1100_MORITZ 1
//#define CC1100_MAICO 3


Aktiviert wird der Empfang dann mit:
X21
Zr


Es kommen beide Nachrichtenarten über den gleichen Port. Irgendwann möchte ich es dann noch so umbauen, dass sich die zusätzlichen Transceiver wie ein STACKABLE_CC einbinden lassen.

Vielen Dank für die schnelle Antwort.

Okay ... das Ziel (auch wenn es bislang noch nicht vollständig umgesetzt ist) klingt sehr gut, quasi ein stackable CC (oder CUNX) zu entwickeln. Schnell genug für das "handling" von mehreren CC1101 ist der STM32 ist jedem Fall und Speicher ist im Vergleich zum atm328p ja ohnehin mehr verfügbar. Ich bin mal gespannt, es scheint mir ein wichtiges Projekt zu sein/werden.


Viele Grüße!

Andreas
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 21 Dezember 2016, 16:55:01
Ich hab mal etwas weitergepinselt und werde mir vermutlich zuerst die größere Version herstellen lassen.
https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large

Anbei mal der Zwischenstand. Den will ich morgen nochmals in Ruhe checken.

Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 21 Dezember 2016, 22:25:02
Für eine größere Version hätte ich da noch ein paar Ideen:

Der DBG Stecker sollte die gleiche Belegung wie UART0 und UART1 haben (Pin 1 und 4 vertauschen).

Anstatt für den zweiten CC1101 Transceiver eines der 868MHz Briefmakenmodule vorzusehen, würde ich eine 2x5 Polige Buchse für ein RF1100SE Modul nehmen. Damit lässt sich dann auch 433MHz verwenden. Auch das Pseudo 868MHz Modul RF1101SE-V2 hat die gleiche Belegung. Für das Briefmarkenmodul könnte man eine Adapterplatine machen.

Zusätzlich würde ich noch einen weiteren Steckplatz für ein Transceivermodul vorschlagen. Da an diesem Steckplatz I2C verfügbar ist, könnte man dort auch ein 1-Wire Modul betreiben (Bild im Anhang, ganz rechts).

Und weil es die Programmierung erheblich erleichtert würde ich auch noch eine Cortex Debug Connector vorschlagen, mindestens jedoch den SWD Anschluss.

Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 22 Dezember 2016, 08:59:20
Danke, das hört sich für mich gut an.

Mein Stand:
-die Mini-Platine halte ich für fertig (außer es gäbe noch Fehler die ich übersehen habe, und diese hat zu viele Funktionen wie LAN, aber das macht ja nichts :-)
-eine große Version mit massig Funktion macht Sinn.
-Bei 3 Transceivern wäre bei mir möglicherweise der komplette Bedarf abgedeckt
-Ich sehe das mechanische am wichtigsten bei der großen Version
  -5x2 Pinheader sind recht wackelig, daher will ich mal schauen ob man Stamp und Pinheader vorsehen kann
  -5x5cm wird wohl kaum reichen, daher kann die Planung dann komplett anders aussehen
  -ich gehe mal von max. 5x10 cm aus, kennt jemand ein gutes Gehäuse dazu ?
  -offene Frage für mich ist ein geeignetes LAN Modul, das hier (https://de.aliexpress.com/item/Free-shipping-W5100-Ethernet-module-Ethernet-network-module-for-arduino/32341522510.html) finde ich mechanisch sehr unglücklich weil keine Montagelöcher.
  -Spannungsversorgung: Reichen 4,7-5V / 500mA am USB Anschluss des Maple für drei Transceiver ?
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 22 Dezember 2016, 13:48:22
Zitat von: ranseyer am 22 Dezember 2016, 08:59:20
  -offene Frage für mich ist ein geeignetes LAN Modul, das hier (https://de.aliexpress.com/item/Free-shipping-W5100-Ethernet-module-Ethernet-network-module-for-arduino/32341522510.html) finde ich mechanisch sehr unglücklich weil keine Montagelöcher.
Die alternative wäre dazu ein W5500 (https://de.aliexpress.com/item/Free-shipping-W5500-Ethernet-network-module-hardware-TCP-IP-51-STM32-microcontroller-program-over-W5100/32750316619.html) Modul. Aber was bringen dir Montagelöcher, wenn das Gehäuse keine dazu passende Halter hat?

Zitat von: ranseyer am 22 Dezember 2016, 08:59:20
  -Spannungsversorgung: Reichen 4,7-5V / 500mA am USB Anschluss des Maple für drei Transceiver ?
Das reicht für die Transceiver. Typischerweise 17 mA für RX und 34 mA für TX pro Modul.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 23 Dezember 2016, 15:19:08
ZitatAber was bringen dir Montagelöcher, wenn das Gehäuse keine dazu passende Halter hat?
Dann muss halt die Platine die Löcher bereitstellen...

-Ich habe mal spontan getestet wie 3 Tranceiver auf 5x10cm passen: "zu gut" ...
-Alle Transceiver zum Löten UND stecken nach Wahl
-@Telekatz: kannst/magst Du noch 3 Leitungen herausleiern für nen vierten Transceiver  ? (notfalls halt bei Verzicht auf LAN)


-Gehäuse: Nach wie vor offen. aber ich kann ja mal den Reichelt Katalog rausholen über Weihnachten.


In der Anlage mal ein erster Ansatz um das ganze weiterzudenken...
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 23 Dezember 2016, 17:29:05
Für einen vierten Transceiver kannst du PB0 (CC_CS3) und PC13 (CC_IN3) verwenden. Auf OUT kann bei den meisten FastRF Protokollen verzichtet werden. MAX und HM funktionieren z.B. ohne OUT Leitung.

Für den Cortex Debug Anschluss wird normalerweise ein 2x5 Pinheader im Raster 1,27mm verwendet. Empfehlen würde ich diese Bauform: http://de.farnell.com/amphenol-fci/20021121-00010c4lf/stecker-vert-1-27mm-smt-10wege/dp/1865279 (http://de.farnell.com/amphenol-fci/20021121-00010c4lf/stecker-vert-1-27mm-smt-10wege/dp/1865279).

Lassen sich die Transceiver auch so anordnen, dass abwechselnd der Antennenanschluss oben und unten ist. Wenn die Antenne alle so nah nebeneinander sind, könnte das Probleme mit gegenseitiger Beeinflussung geben. Ich hab mal bei meinem Cube probiert, 4 Transceiver gleichzeitig zu benutzen. Drei davon waren direkt nebeneinander angeordnet. Selbst wenn alle nur auf Empfang geschaltet waren, gab es schon Probleme.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 25 Dezember 2016, 18:05:19
Ich habe mal etwas nachgedacht und geforscht. Einen professionellen Abstand der Antennen schaffen wir kaum.

433 MHz = 70cm Wellenlänge, auch nur 50% davon ist noch recht viel: 35cm
866 MHz = ~35cm      und 50% davon (notfalls sind immer noch fast 15-20cm

Mechanisch sind mir 3 Versionen eingefallen die wenig kosten

10x10 cm
Will ich nicht unbedingt verfolgen da mir kein passendes Kompaktgehäuse aufgefallen ist

5+10 cm mit Kopplungsmöglichkeit
-mit der Möglichkeit zwei Platinen (1*oben/unten gedreht zu koppeln; bzw. auf einem Nutzen gleich so verbunden herstellen zu lassen)
-Machbar, aber sicher reichlichst VIAs und eine Höllenarbeit beim Design
-natürlich könnte man die Platinen auch mit Entfernung betreiben (z.B. an beiden Enden in einem Gehäuse für 10x16cm Platinen)

5x10cm
- Denke so werde ichs weiterentwickeln. Gehäuse für 5x10 bis 16x10cm sinnvoll... Reichlich Auswahl.
-Möglicherweise etwas breiter als 5cm, passend zum folgenden Gehäuse
- Zusätzlich dieses Gehäuse möglich: https://www.reichelt.de/Kunststoff-Kleingehaeuse/GEH-KSW-35/3/index.html?ACTION=3&LA=446&ARTICLE=73227&GROUPID=7715&artnr=GEH+KSW+35&SEARCH=geh%2Bksw%2B35
- Wer nur an mit einem USB Port 4 Antennen mit Abstand will muss ggf zwei Antennen per Kabel verlängern und Buchsen direkt am Gehäuse vorsehen. Sowas meine ich: https://www.reichelt.de/Bopla-Ecoline-Alubos-Topline-Gehaeuse/2/index.html?ACTION=2&LA=2&GROUPID=7723
- Also eher ein System mit reichlich Möglichkeiten als eine starre Umsetzung
- Zu Störungen bei reinem Empfang frage ich mich woher diese kommen. Auf jeden Fall sehe ich 22pF Cs bei jedem Transceiver nach VCC vor.  Generell noch ein Fetter C. Was ich mich frage ob über die Datenleitungen auch Probleme in den Transceiver eingeschleppt werden könnten ?
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 26 Dezember 2016, 19:45:51
Nun dann muss man halt die Antenne mit einer Leitung abgesetzt aufstellen, wenn es Störungen gibt.

Ich hab heute mal etwas herumgespielt, wie man das inklusive W5100 platzsparen auf einer 5x10 cm Platine unterbringt. Das Ergebnis ist im Anhang.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 26 Dezember 2016, 22:59:45
Das sieht schick aus ! (Welches Programm nutzt du ?)
Da ich noch nicht ganz fertig bin (zweites LAN Modul fehlt noch) nur mal in dieser Form.

ed:
-Bei mir stehen die Steckmodule aus der Hauptplatine heraus. Also passend für größere Gehäuse.
-die Stamps passend zum verlinkten Reichelt-Gehäuse.
- und dann wollte ich noch das andere LAN Modul als Option verschraubbar mit der Platine vorsehen.
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 27 Dezember 2016, 20:00:45
Ich benutze den Circuitmaker von Altium.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 27 Dezember 2016, 20:31:53
So, habe mal nen Stand fertig. Fehler sind sicher nicht ausgeschlossen. Daher habe ich ganz sicher nichts gegen ein Review:
https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large

Ansonsten schaue ich selbst morgen nochmals drüber und bestelle dann. (Ein Board max 10x10cm mit der großen und kleinen Ausführung auf einem Nutzen)


Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 27 Dezember 2016, 23:16:45
Mir ist folgendes aufgefallen:

SWCLK und SWDIO sind am Cortex Debug Connector nicht angeschlossen (Unterschiedliche Netznamen am Maple und Debug Connector)

Bei der Belegung des W5100 ist mir im Schaltplan ein Fehler unterlaufen. Die Belegung ist Spiegelverkehrt.

Die Abblockkondensatoren an den CC1101 Modulen sind schlecht angeschlossen. Sie sind zwar räumlich nah an den Versorgungspins angeordnet, aber die Leiterbahnführung macht den Nutzen zunichte. Hat das ein Autorouter geroutet? Für eine bessere Anbindung: http://www.lothar-miller.de/s9y/categories/14-Entkopplung (http://www.lothar-miller.de/s9y/categories/14-Entkopplung)
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 28 Dezember 2016, 13:15:26
Danke für die Rückmeldung.

-Die beiden fehlenden Pins habe ich nachverdrahtet
-Spiegelung LAN ist kein Problem, da ich einfach den Connector nach unten gelegt hatte
-Die C's: Ja die waren schlecht. Allerdings war nicht Freerouting schuld, sondern ich durch dumme Platzierung. Hatte vergessen diese nach oben zu holen bei Umbauten...

Ich habe mal einen ersten Satz bestellt (10). (die kleinen Platinen sind zwei mal enthalten, jedoch grenzwertig falls LAN genutzt werden soll)
Der Stand wie immer: https://github.com/ranseyer/CUN-STM32

Jetzt heisst es für mich mal länger Warten: Falls Langweile aufkommt evtl. mal in die SW schauen.

ed: Keine Ahnung wie lange der Link funktioniert: https://www.seeedstudio.com/gerber-view.html?sn=4c43c53ecced11e69ed5026a86b9cae7
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 04 Januar 2017, 20:11:07
Hi,
bekomme meinen Maple nicht geflashed.
Könnt ihr mir helfen?
Habe alles gemacht wie in der Anleitung beschrieben.

USB/TTL habe ich diesen und auf 3.3V http://www.ebay.de/itm/182236876827?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
RX/TX mit rx1/tx1 verbunden. (siehe Bild)

Benutze Flash Loader Demonstrator.
Fehlermeldung ist immer: "No reponse from the target, the Boot loader can not be started." (siehe Bild)

Vielen Dank schonmal,
Stefan
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 04 Januar 2017, 20:26:01
Du musst RX und TX über Kreuz anschließen. Und schließ noch den GND an.
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 04 Januar 2017, 23:52:42
Hi Telekatz,

sorry immer noch kein Erfolg.
Hab nun sogar noch VCC mit angeschlossen und den USB am Maple weggelassen auch nix.

Ist es normal dass der Maple wenn er strohm bekommt 5x schnell blinkt und dann etwas langsamer dauerhaft blinkt.
Drücke ich die but=32 und halte sie passiert erst mal nix, drücke ich dann reset und lasse beide los geht die LED aus.

Der Loader erkennt ihn aber immer noch nicht.
Noch eine Idee?

Gruß,
Stefan
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 05 Januar 2017, 00:08:38
Ok,

nach mehrmaligem hin und her konnte ich nun wohl die MapleCUL.bin flashen.
Schließe ich ihn nun an den Raspberry an blinkt die LED im sekunden Takt.
Auf der console mit  ls -ltr /dev/serial/by-id/ erhalte ich aber 3 Devices.
lrwxrwxrwx 1 root root 13 Jan  5 00:02 usb-STM32_MapleCUL_b9af0589-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan  5 00:02 usb-STM32_MapleCUL_b9af0589-if04 -> ../../ttyACM2
lrwxrwxrwx 1 root root 13 Jan  5 00:02 usb-STM32_MapleCUL_b9af0589-if02 -> ../../ttyACM1

Habe das 0er mal als CUL im FHEM angelegt. Wird aber nicht connected.
Was mache ich falsch?

Gruß und Danke,
Stefan
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 05 Januar 2017, 10:27:34
Zitat von: stefanru am 05 Januar 2017, 00:08:38
Auf der console mit  ls -ltr /dev/serial/by-id/ erhalte ich aber 3 Devices.
lrwxrwxrwx 1 root root 13 Jan  5 00:02 usb-STM32_MapleCUL_b9af0589-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan  5 00:02 usb-STM32_MapleCUL_b9af0589-if04 -> ../../ttyACM2
lrwxrwxrwx 1 root root 13 Jan  5 00:02 usb-STM32_MapleCUL_b9af0589-if02 -> ../../ttyACM1
Der CUL ist dem ersten Device zugeordnet (ttyACM0). Die beiden anderen Devices gehen direkt an die beiden freien seriellen Schnittstellen des Maples.

Zitat von: stefanru am 05 Januar 2017, 00:08:38
Habe das 0er mal als CUL im FHEM angelegt. Wird aber nicht connected.
Was mache ich falsch?
Rechte korrekt vergeben?
http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt (http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt)
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 05 Januar 2017, 13:32:31
Wow!

War mein Fehler. Hatte noch ein Tippfehler beim Device.
Sieht jetzt erstmal gut aus.
Dann baue ich heute Abend nochmal selbst die FW und hänge den CC1101 dran.

Ist ja echt super, DANKE!
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 05 Januar 2017, 18:10:21
Hab doch noch eine Frage.

Wie unterscheide ich 433 und 868?
Gibt ja nur ein bin file.
Oder geht einfach beides?

Gruß,
Stefan
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 05 Januar 2017, 18:45:18
Es gibt nur eine Version, in der dann alle Protokolle enthalten sind. Platz ist schließlich noch genug vorhanden.
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 05 Januar 2017, 19:25:04
Ok vielen Dank!
Funktioniert super!
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 21 Januar 2017, 22:55:53
Hi,
wollte die neue CUL Software draufspielen und hab schon wieder Probleme.

Bin nach Anleitung vorgegeangen und diesmal direkt zum Flashen gekommen.
Bei 25% hat es aufgehört und es ging nix mehr.
Nun ist der maple tot. Also beim einstecken blinkt nix mehr und er wird auch nicht von win als Maple?? erkannt.

Ich habe mitlerweile noch einen weiteren maple.
Also versucht diesen zu flashen. Hier wieder die alten Probleme ich komme erst gar nicht rein.
Gehe genau nach Anleitung vor.

Habe nun auch noch wie beim letzten mal als es auf einmal ging VCC und GND vom FTDI.

RX/TX sind über kreuz.

Gibt es noch irgendwelche Tips?

Woran kann das bloß liegen? Mein FTDI hat nen switch. Er steht auf 3.3V.

Gruß,
Stefan
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 21 Januar 2017, 23:21:57
Zitat von: stefanru am 21 Januar 2017, 22:55:53
Bin nach Anleitung vorgegeangen und diesmal direkt zum Flashen gekommen.
Bei 25% hat es aufgehört und es ging nix mehr.
Nun ist der maple tot. Also beim einstecken blinkt nix mehr und er wird auch nicht von win als Maple?? erkannt.
Man kann den Maple nicht kaputtflashen. Der Bootloader ist Teil des STM32 und kann nicht gelöscht werden.  Wenn es abbricht, Bootloader wieder wie beschrieben aktivieren und es nochmal versuchen. Falls es mit dem STM32 Flash loader demonstrator nicht funktioniert, probier es mal mit Stm32flash.
Bei meinem Maple funktionierte es auch erst nach mehreren Versuchen.
Titel: Antw:Selbstbau CUN
Beitrag von: stefanru am 21 Januar 2017, 23:42:26
Ok,
schonmal gut das man ihn nicht kaputt flashen kann.
Dass er garnichtmehr leuchtet und auch nicht als usb gerät erkannt wird macht nix?

Versuche es jetzt mit dem neuen seit 2 Stunden. Es klappt nicht.
Habe es auch schon mit Stm32flash versucht. Auch ohne Erfolg.
Gibts denn noch irgendwas zu beachten?

Ich mache immer wieder USB am FTDI rein. Neuer Maple blinkt. Ich drücke but32 dnach reset. Lasse reset und but32 los.
Maple blinkt nicht mehr.
Drücke bei der Software mit den vorgegebenen Einstellungen (115200, even,disabled, 1) next.
Immer die meldeung dass es nicht geht.

Habe auch schon mit 57600 probiert geht auch nicht.

Noch irgendein tip?


P.S.: Es geht wieder!
Ich weiß nicht genau was es war habe aber ein paar Tips.
Meine Tips:
Schaut im Devicemanager und macht nochmal die Einstellungen beim COM Port. Also 115200, 8 , Gerade, 1, Keine
Macht den Flashloader auf und lasst Ihn offen.
Schließt alles an.
Drückt But=32 und haltet ihn, danach reset drücken, am besten mehrmals, kurz, lang... am Schluss den reset loslassen danach den BUT32.
Nun versuchen im Flashloader.
Geht es nicht direkt weiter nochmal die tasten wie oben beschrieben drücken. Beim 4ten - 5ten mal gings bei mir nun.

Danke und Gruß,
Stefan

Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 26 Januar 2017, 16:25:12
Falls jemand mal eine fertige Platine probieren will: Einfach melden.
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 27 Januar 2017, 18:33:53
Zu Testen der zusätzlichen Transceiver habe ich einen neuen Branch in der a-culfw angelegt: https://github.com/heliflieger/a-culfw/tree/multiCC (https://github.com/heliflieger/a-culfw/tree/multiCC)

Die zusätzlichen Transceiver werden als STACKABLE_CC angelegt.
define mapleCUN1 CUL 192.168.69.100:2323 1234
define mapleCUN2 STACKABLE_CC mapleCUN1
define mapleCUN3 STACKABLE_CC mapleCUN2
define mapleCUN4 STACKABLE_CC mapleCUN3


Es sind noch nicht alle Protokolle an den zusätzlichen Transceivern verfügbar. Auch SlowRF funktioniert momentan nur am ersten Transceiver.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 27 Januar 2017, 21:47:15
Danke !

Hast Du nen Tipp was man tun müsste um eine Firmware zu erhalten die mit dem MAPLE Bootloader funktioniert ?
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 27 Januar 2017, 23:37:42
Ich schätze mal die Startadresse im .ld File ändern und den Startup Code anpassen. Aber welche Anpassungen es genau sein müssen, weiß ich auch nicht.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 27 Januar 2017, 23:41:39
OK das heisst für mich warten bis weitere MAPLE's mit der Post kommen. Ich habe nur einen, und will noch etwas anderes testen...
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 30 Januar 2017, 22:16:47
Anbei eine weitere Testversion des multiCC Branches. Diesmal funktioniert SlowRF auch an den ersten beiden Transceivern gleichzeitig. Vorzugsweise 868MHz am ersten und 433MHz am zweiten Transceiver.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 01 Februar 2017, 08:56:28
Danke fürs Bereitstellen. Jetzt warte ich noch auf ein 433MHz Modul...

Platinen zum Projekt sind übrigens eingetroffen: https://forum.fhem.de/index.php/topic,50990.0.html

Allerdings warte ich noch auf Feedback um eine zweite Charge anzustossen...
(Beim Feedback geht es mir vor allem um die mechanische Anordnung)
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 02 Februar 2017, 12:48:45
Danke die neue Firmware funktioniert auch bei mir.
(CUL angelegt, der zweite  als Stackable)


Zitatdefine CULtest866 CUL /dev/ttyACM0@38400 4444
attr CULtest866 rfmode HomeMatic
attr CULtest866 verbose 5
define mapleCUN433 STACKABLE_CC CULtest866
attr mapleCUN433 rfmode SlowRF
attr mapleCUN433 verbose 5


Zitat2017.02.02 12:12:50 5: CULtest866: dispatch *i05055433
2017.02.02 12:12:50 4: CUL_Parse: mapleCUN433 i05055433 -48.5
2017.02.02 12:12:50 5: mapleCUN433: dispatch i050554
2017.02.02 12:12:50 4: mapleCUN433 IT: message "i050554" (7)
2017.02.02 12:12:50 4: mapleCUN433 IT: msgcode "00FF00FFFFF0" (12) bin = 000001010000010101010100
2017.02.02 12:12:50 5: mapleCUN433 IT: V1 housecode = 00FF00FFFF  onoffcode = F0
2017.02.02 12:12:50 3: mapleCUN433 IT: EG.Kueche.Stripe off->off
2017.02.02 12:12:50 5: CUL/RAW: /*i05155F35

Der Aufbau ist siehe Foto. Hässlich daran ist die Mischbestückung, aber 433 MHz Stamps waren nur in China zu bekommen.

Ich würde dann mal gerne einen Wiki Artikel starten. Wie wäre es mit "CUN-STM32" ?

Titel: Antw:Selbstbau CUN
Beitrag von: PeMue am 02 Februar 2017, 18:10:58
Hallo zusammen,

ich bin noch am Einlesen, schaue mir aber auf jeden Fall mal die große Platine an. Das geht auch kleiner ;)
Daher - Martin bitte verzeih mir - warte ich auf die zweite Charge groß.
Die Bauteile sind schon in der Aliexpress Wunschliste ;D

Gruß Peter
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 02 Februar 2017, 19:02:35
Ja klar geht das kleiner. Nur wollte ich reichlich Abstand zwischen den Antennen. Zwischen 433 und 866 etwas weniger. Wenn man das nicht so macht müssten die Buchsen per Kabel abgesetzt werden. (Meine Meinung...)

Gesendet von meinem HTC One_M8 mit Tapatalk
Titel: Antw:Selbstbau CUN
Beitrag von: PeMue am 02 Februar 2017, 19:12:32
Zitat von: ranseyer am 02 Februar 2017, 19:02:35
Nur wollte ich reichlich Abstand zwischen den Antennen. Zwischen 433 und 866 etwas weniger. Wenn man das nicht so macht müssten die Buchsen per Kabel abgesetzt werden. (Meine Meinung...)
Ok, habe ich verstanden. Aber die 433 MHz Module würde ich anders anordnen. Ich lese mich mal ein und mache Vorschläge (falls Du nichts dagegen hast  ;)).

Gruß Peter
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 02 Februar 2017, 20:26:55
Als 433 MHz Modul würde hier ja auch ein Briefmakenmodul besser passen.

@ranseyer
Ich habe dein Board mal kurz getestet und bis auf die beiden fehlenden Leitungen hat alles funktioniert.
Getestet habe ich SlowRF866 an CC0, SlowRF433 an CC1, HM an CC2 und MAX an CC4 (da passt der Bestückungsdruck nicht). Allerdings nur jeweils an den 10 poligen Pinheadern.

W5100, CTX-DB und die drei seriellen Schnittstellen funktionieren auch.

Zitat von: ranseyer am 02 Februar 2017, 12:48:45
Ich würde dann mal gerne einen Wiki Artikel starten. Wie wäre es mit "CUN-STM32" ?
Wenn es ein Artikel um CULs/CUNs auf Basis des Maple minis werden soll, würde ich beim Namen MapleCUN bleiben.
Titel: Antw:Selbstbau CUN
Beitrag von: PeMue am 02 Februar 2017, 21:45:32
Zitat von: Telekatz am 02 Februar 2017, 20:26:55
Getestet habe ich SlowRF866 an CC0, SlowRF433 an CC1, HM an CC2 und MAX an CC4 (da passt der Bestückungsdruck nicht). Allerdings nur jeweils an den 10 poligen Pinheadern.
"Missbrauchst" Du da nicht die 433 MHz Antennen für 868 MHz? So wie es aussieht, ist nur das linke obere ein echtes 868 MHz Modul  ;)

Gruß PeMue
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 02 Februar 2017, 22:25:01
Zitat"Missbrauchst" Du da nicht die 433 MHz Antennen für 868 MHz?

433Mhz würde knapp 70 cm Wellenlänge (Lambda) ergeben. Auch abgewickelt sind diese Antennen das nicht, sondern vermutlich nur Lamda/4
Somit könnte diese bei 868 Mhz durchaus besser funktionieren als die "richtigen".

Nur muss man dann irgendwann mal wieder aufpassen das es nicht zu gut wird mit der abgestrahlten Leistung (ERP, aus rechlicher Sicht z.B.).
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 02 Februar 2017, 22:29:42
Es sind die Antennen, die bei meinen RF1101SE-V2 Module dabei waren. Die grünen Module selber sind jedoch richtige 868MHz Module. In diesem Beitrag (https://forum.fhem.de/index.php/topic,60458.msg544605.html#msg544605) sieht man es deutlicher. Es ist das dritte Modul. Das Modul links oben sieht nur deshalb anders aus, weil es der selbsthergestellte Prototyp ist.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 03 Februar 2017, 16:00:17
Hier gibt es den Anfang eines Wiki Artikels: https://wiki.fhem.de/wiki/MapleCUN
Wäre schön wenn sich noch andere einbringen würden...
Titel: Antw:Selbstbau CUN
Beitrag von: PeMue am 03 Februar 2017, 16:14:32
Hallo zusammen,

ich habe mir das Ganze mal angeschaut und folgende Fragen:
- Der Maple CUx [x=L|N] kann 4 Radios oder alternativ 2 Radios und 2 serielle Schnittstellen (oder halt 3 Radios und eine serielle Schnittstelle), korrekt?
- Welches Radio müsste den seriellen Schnittstellen weichen, oder ist das egal?
- Wie wird die Trennung der seriellen Datenströme bei USB Verbingung gemacht, gibt es dann mehrere serielle Schnittstellen auf USB?

Meine Idee für die Platine:
- 4 Radios (SMD oder alternativ die 433 MHz Module)
- optional eine HM-UART Modul an einer seriellen Schnittstelle (ein Radio entfällt dafür)
- optional einen Arduino pro mini Nachbau (Minimalversion) mit NRF24L01+ für ein MySensors Gateway an der anderen seriellen Schnittstelle (ein Radio entfällt dafür)
- optional LAN Modul (W5100 oder W5500?)
- ein WAF-fähiges Gehäuse

Das wäre aus meiner Sicht die Wunderwaffe, SlowRf 868 bzw. 433 MHz/Homematic/MySensors in einem Gateway.

@ranseyer:
Ich schau mir mal den Artikel an, aber momentan fehlt mir noch das Wissen.

Gruß PeMue
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 03 Februar 2017, 16:45:41
Ich hänge mal die Maße des 5100 LAN Moduls an.
Das 5500 besitze ich nicht, davon gibt es hier zwei Bilder: https://github.com/ranseyer/CUN-STM32/blob/master/w5500-NiRen2.jpg Theoretisch kann man versuchen davon Maße abzuleiten.
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 03 Februar 2017, 16:52:27
Der MapleCUN legt über USB 3 Ports an und ist über Netzwerk über die Ports 2323, 2324 und 2325 erreichbar. Über den ersten USB Port oder über den Netzwerkport 2323 sind die 4 Radios ansteuerbar. Die Unterscheidung der unterschiedlichen Radios erfolgt wie bei einem STACKABLE_CC über entsprechend viele * vor der Nachricht.

Die beiden serielle Schnittstellen UART0 und UART1 sind über die anderen zwei USB Ports bzw. Netzwerkports ansteuerbar. Von der Funktion ist das nichts anderes als ein USB zu seriell Wandler bzw. Netzwerk zu seriell Wandler.  Der dritte serielle Anschluss DBG ist nur zum Firmware laden vorgesehen.

Es geht also gleichzeitig:

Allerdings habe ich auch noch den Plan, anstatt des dritten Radios auch ein 1-Wire Modul anzusteuern. Quasi ein CUNOx3. 
Titel: Antw:Selbstbau CUN
Beitrag von: PeMue am 03 Februar 2017, 22:05:33
Zitat von: Telekatz am 03 Februar 2017, 16:52:27
Es geht also gleichzeitig:

  • 4 Radios
  • zwei serielle Schnittstellen
  • W5100 oder W5500 (noch nicht getestet)
Wow, das ist ja eine richtig coole Sache. Sprich ich komme meinem Gateway mit: Homematic/SlowRF 433/SlowRF 868/MySensors Gateway (oder serieller Schnittstelle über NRF) immer näher  :)

Zitat von: Telekatz am 03 Februar 2017, 16:52:27
Allerdings habe ich auch noch den Plan, anstatt des dritten Radios auch ein 1-Wire Modul anzusteuern. Quasi ein CUNOx3.
Was stellst Du Dir als Hardware vor? Nur einen Pin? Oder einen 1-wire Busmaster? Wenn ja, welchen?

Danke + Gruß

PeMue
Titel: Antw:Selbstbau CUN
Beitrag von: Telekatz am 03 Februar 2017, 22:38:09
Zitat von: PeMue am 03 Februar 2017, 22:05:33
Was stellst Du Dir als Hardware vor? Nur einen Pin? Oder einen 1-wire Busmaster? Wenn ja, welchen?
Einen DS2482 wie beim CUNO auch. Dafür ist auch schon der Code in der Firmware vorhanden.
Titel: Antw:Selbstbau CUN
Beitrag von: locutus am 06 Februar 2017, 00:50:19
Zitat von: Telekatz am 17 Dezember 2016, 20:19:37
Mittlerweile funktioniert auch der Zugriff auf die beiden freien seriellen Schnittstellen. Über USB werden dabei zwei weitere Schnittstellen angelegt, der Netzwerkzugriff erfolgt über die Ports 2324 und 2325.
Ein am UART0 angeschlossener HM-MOD-UART kann z.B. mit folgender Definition in FHEM eingebunden werden:
define myRemoteHmUART HMUARTLGW uart://192.168.42.23:2324
Ich hab's mit der HM-MOD-UART getestet. Die serielle Anbindung funktioniert leider nicht! Der MapleCUN steigt komplett aus – Status disconnected. UART Baudrate eingestellt, TX und RX vertauscht, ohne Erfolg. Hat außer mir jemand die gleiche Erfahrung gemacht?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 Februar 2017, 09:45:25
Ich hab es gestern getestet und es hat funktioniert. RX vom Maple mit TX vom HM-MOD-UART und TX vom Maple mit RX vom HM-MOD-UART angeschlossen.

Hast du es auch schon über den anderen Port (2325) getestet? Um Fehler bei der Baudrate auszuschließen kannst du es auch mal direkt über USB testen. Da wird die Baudrate genommen, die der Host beim öffnen der Schnittstelle vorgibt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 06 Februar 2017, 09:46:37
Guten Tag,

Frage: Hat schon jemand ein erfolgreichen Versuch mit einem W5100 (o.W5500) gemacht ?

Ich denke, dass die Platinen in Kürze bei mir ankommen und dann werde ich die Ethernetanbindung mal probieren.


Viele Grüße!

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 06 Februar 2017, 11:38:37
Zitat von: Telekatz am 06 Februar 2017, 09:45:25
Hast du es auch schon über den anderen Port (2325) getestet?
Nö, ich bin davon ausgegangen, dass der Port 2324 für UART0 und Port 2325 für UART1 fest voreingestellt ist.

ZitatUm Fehler bei der Baudrate auszuschließen kannst du es auch mal direkt über USB testen. Da wird die Baudrate genommen, die der Host beim öffnen der Schnittstelle vorgibt.
Danke! Die Anbindung via USB funktioniert:
define myRemoteHmUART HMUARTLGW /dev/ttyACM1

Zitat von: fhem-challenge am 06 Februar 2017, 09:46:37
Frage: Hat schon jemand ein erfolgreichen Versuch mit einem W5100 (o.W5500) gemacht ?
Ja, mit W5100. USR-ES1 W5500 ist schon bestellt.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 Februar 2017, 11:40:52
W5100 ist getestet und funktioniert. W5500 ist noch ungetestet. Wer das testen will, muss sich momentan noch die Firmware aus dem multiCC Branch selber kompilieren.

Zitat von: locutus am 06 Februar 2017, 11:38:37
Nö, ich bin davon ausgegangen, dass der Port 2324 für UART0 und Port 2325 für UART1 fest voreingestellt ist.
Danke! Die Anbindung via USB funktioniert:
define myRemoteHmUART HMUARTLGW /dev/ttyACM1
Ist auch fest vorgegeben. Wenn es über ACM1 läuft, dann sollte es auch über Port 2324 laufen. Setz mal mit "e" die Konfiguration des MapleCUN zurück.
Titel: Antw:Selbstbau CUN
Beitrag von: Ranseyer am 06 Februar 2017, 18:32:06
Zitat von: Telekatz am 03 Februar 2017, 22:38:09
Einen DS2482 wie beim CUNO auch. Dafür ist auch schon der Code in der Firmware vorhanden.


Hast Du Lust den Schaltplan dazu zu erweitern ?

Warum ? -ich habe keine Platinen mehr und will nochmals rasch bestellen. Zwar brauche ich kein OneWire (und wahrscheinlich auch kein LAN), denke aber dass noch Platz wäre... :-)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 Februar 2017, 19:15:56
Ich hatte das ursprünglich in der Bauform eines RF1100SE Moduls geplant. Es sollte dann anstatt eines Transceivermoduls verwendet werden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 06 Februar 2017, 21:34:56
Zitat von: Telekatz am 06 Februar 2017, 11:40:52
Wenn es über ACM1 läuft, dann sollte es auch über Port 2324 laufen. Setz mal mit "e" die Konfiguration des MapleCUN zurück.
Die Anbindung über ttyACM1 und ttyACM2 klappt. Der Netzwerkzugriff über die Ports 2324 und 2325 schlägt fehl. Beide Ports sind frei:

nmap -Pn -p2325 192.168.178.22
Starting Nmap 6.47 ( http://nmap.org ) at 2017-02-06 21:10 CET
Nmap scan report for 192.168.178.22
Host is up (0.0018s latency).
PORT     STATE SERVICE
2325/tcp open  ansysli
Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds

nmap -Pn -p2324 192.168.178.22
Starting Nmap 6.47 ( http://nmap.org ) at 2017-02-06 21:10 CET
Nmap scan report for 192.168.178.22
Host is up (0.0038s latency).
PORT     STATE SERVICE
2324/tcp open  unknown
Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds


Ich befinde mich auf dem Holzweg!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 Februar 2017, 22:11:42
Läuft die Verbindung über Port 2323 ohne Probleme?

Schon mal RX und TX am Maple miteinander verbunden und mit einer Terminalverbindung einen Loopback Test gemacht?

Welch Firmwareversion hat dein HM-MOD-UART?

Teste auch mal die MapleCUNx4 Version aus diesem Beitrag: https://forum.fhem.de/index.php/topic,60458.msg573491.html#msg573491 (https://forum.fhem.de/index.php/topic,60458.msg573491.html#msg573491)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 07 Februar 2017, 00:12:20
MapleCUNx4 auf Port 2323 ist im Netzwerk verfügbar. HM-MOD-UART Firmware 1.4.1. Es kann nur noch am W5100 liegen. Ich werde mir ein neues LAN-Modul bestellen müssen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Februar 2017, 09:24:08
Über den DBG Anschluss kommen im Betrieb Debugmeldungen, wenn eine Netzwerkverbindung aufgebaut wird. Hänge dich mal da dran (115200 Baud) und Log die Ausgaben mit.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 07 Februar 2017, 22:52:35
Das "define myRemoteHmUART ... 2324" führt zu einer Endlosschleife...

0:Connected - 192.168.178.35 : 52918
0:Set RF mode to 1
1:Connected - 192.168.178.35 : 39686

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Jan 30 2017 22:05:53 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:0E:C9:AC
IP : 192.168.178.22
GW : 192.168.178.1
SN : 255.255.255.0
=======================================
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]
1:Connected - 192.168.178.35 : 39688

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Jan 30 2017 22:05:53 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:0E:C9:AC
IP : 192.168.178.22
GW : 192.168.178.1
SN : 255.255.255.0
=======================================
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]
1:Connected - 192.168.178.35 : 39690

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Jan 30 2017 22:05:53 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:0E:C9:AC
IP : 192.168.178.22
GW : 192.168.178.1
SN : 255.255.255.0
=======================================
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]
1:Connected - 192.168.178.35 : 39692

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Jan 30 2017 22:05:53 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:0E:C9:AC
IP : 192.168.178.22
GW : 192.168.178.1
SN : 255.255.255.0
=======================================
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]
1:Connected - 192.168.178.35 : 39694

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Jan 30 2017 22:05:53 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Februar 2017, 23:06:06
Funktioniert DHCP auch? Und hast du schon mal mit "raw e" die Konfiguration des MapleCUN zurückgesetzt?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 07 Februar 2017, 23:36:01
Ja, mit "raw e" zurückgesetzt, DHCP ist abgeschaltet.
Wid00
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 08 Februar 2017, 13:09:40
Hallo zusammen,
funktioniert mit dem maplecun auch Infrarot senden?
Das wäre für mich sehr interessant.
Gruß
Matthias
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 08 Februar 2017, 17:55:51
Zitat von: Telekatz am 06 Februar 2017, 19:15:56
Ich hatte das ursprünglich in der Bauform eines RF1100SE Moduls geplant. Es sollte dann anstatt eines Transceivermoduls verwendet werden.

Danke noch. Zwar habe ich das Thema studiert. Aufgrund eines Inputs von PeMue habe erst mal diesen abgearbeitet um die HW-Versionen nicht auseinander laufen zu lassen.
Das Thema ist keines Falls vergessen, aber jetzt ist erst mal 2-3 Tage anderes angesagt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Februar 2017, 19:42:40
Zitat von: matthias soll am 08 Februar 2017, 13:09:40
Hallo zusammen,
funktioniert mit dem maplecun auch Infrarot senden?
Das wäre für mich sehr interessant.
Gruß
Matthias
Nein, Infrarot funktioniert nicht.

@locutus
Kannst du mal die angefügte Version ausprobieren und wieder am DBG Anschluss Loggen. Ich hab da noch ein paar zusätzliche Debugmeldungen eingebaut um den Fehler eventuell besser bestimmen zu können.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 08 Februar 2017, 23:08:16
Hi,
hab mir diesen 868 cc1101 besorgt.
Jetzt habe ich gesehen dass die Pins nicht wirklich passen und 10 Stück sind.

Kann man den verwenden? Und wenn ja wie ist er anzuschließen.

Vielen Dank,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Februar 2017, 23:30:25
Das ist kein CC1101 sondern ein SI4463. Steht ja auch drauf. Den kann man nicht verwenden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 09 Februar 2017, 00:18:24
Oh mist, war dann wohl in ebay falsch beschreiben.
Mit dem kann man nix anfangen? :-)
So ein mist...

Gruß und Danke,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 Februar 2017, 17:03:53
Hallo,

mal ne ketzerische Frage:
https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=70504;image
Das W5100 Modul hat 5 V Versorgung, d.h. die Ausgänge werden vermutlich auch 5 V haben. Verkraftet das der mapleMini (der ja intern mit 3,3 V arbeitet), oder sollte man lieber einen Spannungsteiler vorsehen?

Danke + Gruß

Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 Februar 2017, 17:17:01
Der STM32 ist 5V tolerant. Im Zweifelsfall Mal nen Blick ins Datenblatt machen...

Gesendet von meinem HTC One_M8 mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 09 Februar 2017, 17:45:54
Der W5100 arbeitet auch mit 3,3V. Auf dem W5100 Modul ist ein 3,3V Spannungsregler für die Versorgung des W5100.

Desweiteren sei noch erwähnt, dass der STM32 nicht an allen Pins 5V tolerant ist.  Die Pins für UART0 sind es zum Beispiel nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 09 Februar 2017, 19:15:47
Zitat von: Telekatz am 08 Februar 2017, 19:42:40
@locutus
Kannst du mal die angefügte Version ausprobieren und wieder am DBG Anschluss Loggen. Ich hab da noch ein paar zusätzliche Debugmeldungen eingebaut um den Fehler eventuell besser bestimmen zu können.

Verschlingt der Debugmodus so viel Speicherkapazität oder hast du noch weitere Funktionen implementiert?
-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Feb  8 2017 19:12:32 --
-I- Reset Source 24
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:0E:C9:AC
IP : 192.168.178.22
GW : 192.168.178.1
SN : 255.255.255.0
=======================================
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]
1:Connected - 192.168.178.35 : 38944
1:NET_UART_TRANSMIT: 8
-I-

[Hard fault handler - all numbers in hex]-I- R0 = 0
-I- R1 = 5c
-I- R2 = 20002410
-I- R3 = 0
-I- R12 = ffffffbf
-I- LR [R14] = 800d219  subroutine call return address
-I- PC [R15] = 8014002  program counter
-I- PSR = 1000036
-I- BFAR = e000ed38
-I- CFSR = 400
-I- HFSR = 40000000
-I- DFSR = 0
-I- AFSR = 0
-I- SCB_SHCSR = 0

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Feb  8 2017 19:12:32 --
-I- Reset Source 24
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:0E:C9:AC
IP : 192.168.178.22
GW : 192.168.178.1
SN : 255.255.255.0
=======================================
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]
1:Connected - 192.168.178.35 : 38948
1:NET_UART_TRANSMIT: 8
-I-

[Hard fault handler - all numbers in hex]-I- R0 = 0
-I- R1 = 5c
-I- R2 = 20002410
-I- R3 = 0
-I- R12 = ffffffbf
-I- LR [R14] = 800d219  subroutine call return address
-I- PC [R15] = 8014002  program counter
-I- PSR = 1000036
-I- BFAR = e000ed38
-I- CFSR = 400
-I- HFSR = 40000000
-I- DFSR = 0
-I- AFSR = 0
-I- SCB_SHCSR = 0

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Feb  8 2017 19:12:32 --
-I- Reset Source 24
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:0E:C9:AC
IP : 192.168.178.22
GW : 192.168.178.1
SN : 255.255.255.0
=======================================
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]
1:Connected - 192.168.178.35 : 38950
1:NET_UART_TRANSMIT: 8
-I-

[Hard fault handler - all numbers in hex]-I- R0 = 0
-I- R1 = 5c
-I- R2 = 20002410
-I- R3 = 0
-I- R12 = ffffffbf
-I- LR [R14] = 800d219  subroutine call return address
-I- PC [R15] = 8014002  program counter
-I- PSR = 1000036
-I- BFAR = e000ed38
-I- CFSR = 400
-I- HFSR = 40000000
-I- DFSR = 0
-I- AFSR = 0
-I- SCB_SHCSR = 0



Inzwischen ist das kompakte W5500 Modul, das ich im November bestellt habe, eingetroffen.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 09 Februar 2017, 19:38:23
Die Optimierung beim kompilieren ist ausgeschaltet, damit sich das mit GDB besser debuggen lässt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 10 Februar 2017, 15:54:07
Zitat von: locutus am 09 Februar 2017, 19:15:47
Inzwischen ist das kompakte W5500 Modul, das ich im November bestellt habe, eingetroffen.

So schnell ?  Hast Du evtl einen Link zum bestellen ? Das Modul gefällt mir mechanisch viel besser als alle anderen bisher.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 10 Februar 2017, 16:29:44
Zitat von: Ranseyer am 10 Februar 2017, 15:54:07
So schnell?  Hast Du evtl einen Link zum bestellen? Das Modul gefällt mir mechanisch viel besser als alle anderen bisher.
Das würde auch besser auf die Leiterplatte passen  ;D

Link siehe hier:
https://de.aliexpress.com/item/F00129-1-Piece-USR-ES1-W5500-Chip-New-SPI-to-LAN-Ethernet-Converter-TCP-IP-Mod/32340624327.html?spm=2114.010208.3.1.tFgKZF&ws_ab_test=searchweb0_0,searchweb201602_1_10065_10068_10000074_10000032_119_10000025_10000029_10000028_10060_10000067_10062_10056_10055_10000062_10054_301_10059_10099_10000022_10000013_10103_10102_10000016_10101_10096_10000018_10000019_10000056_10000059_10052_10053_10107_10050_10106_10051_10000053_10000007_10000050_10084_10083_10000047_10080_10082_10081_10110_10111_10112_10113_10114_10115_10033_10000041_10000044_10078_10079_10000038_10073_10000035_10122_10121,searchweb201603_10,afswitch_1,single_sort_3_price_asc&btsid=48419cbc-0b73-4812-b4fe-3ba433b9bb94

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 10 Februar 2017, 18:30:34
Guten Abend,


heute ist mein W5100 gekommen, also gleich eingebaut.

Problem:

Es läuft schon Einiges, aber im Netzwerkbereich "klemmt" es noch.

1.)  Meine Definition in FHEM:
define mapleCUN1 CUL 192.168.1.133:2323 4434
define mapleCUN2 STACKABLE_CC mapleCUN1
define mapleCUN3 STACKABLE_CC mapleCUN2
define mapleCUN4 STACKABLE_CC mapleCUN3


2.) Mit Wid00 und Wia192.168.1.133 sowie Wig192.168.1.1 usw. liess sich auch alles einstellen.

3.) Ich verwende das Image: https://forum.fhem.de/index.php/topic,60458.msg573491.html#msg573491

4.) Habe im CC0 ein 433 (RF1100SE)
im CC1 ein 868 Modul, CC2,CC4 sind leer

Kurz nach Einschalten des CUN ist der auch für fhem erreichbar. Ein ccconf zeigt mir auch die Werte des CC1:

freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB

... das hält ca. einige Sekunden an (ca. 20s), danach ist der CUN im Netz nur noch "anpingbar --> ICMP" und nicht mehr via TCP:2323 erreichbar. Ich bekomme im FHEM dann lediglich noch "Timeout reading answer for get C0D".

Hat schon jemand den CUN mit W5100 und der grossen Platine länger erfolgreich laufen lassen können ?


Viele Grüße!

Andreas



Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 Februar 2017, 19:12:46
Lass mal die Definition von mapleCUN2 und mapleCUN3 weg wenn da kein Modul bestückt ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 10 Februar 2017, 19:26:16
Zitat von: Telekatz am 10 Februar 2017, 19:12:46
Lass mal die Definition von mapleCUN2 und mapleCUN3 weg wenn da kein Modul bestückt ist.

Habe ich... und danach hab ich die wieder drin.

Jetzt läuft es stabiler (bereits 40 Minuten) und habe nun ein drittes Modul drin.

Ich erreiche nun CC0=433,CC1=868,CC2=868 korrekt (slowRF). IT empängt mein CC0(433) auch schon.

Ich habe den Eindruck, dass es ggf. an der Stabilität von VCC liegt. Ich versorge die ganze Platine mit dem STM32 USB.

Frage: Ist es als Versorgung besser via VCC an den Pins von X4 zu verwenden, anstelle USB vom STM32  ?... aber das wäre ja nun mal 3,3V ... darüber bekomme ich den W5100 nicht in Betrieb. Vielleicht löte ich die 100nF an die Module und ein 10uF an den W5100. Ich habe leider jetzt mein Oszi nicht dabei.

Und wenn ich schon einmal so viel frage, dann gleich noch eine Frage (sorry): Ist im Code auch schon LaCrosse a'la "Nr2" implementiert ? Denn hier würde sich der MapleCUN sehr lohnen (ein RFM69 geht ja nunmal nicht)... ich würde dann einen der vier CC1101 (868) mit "Nr2" meine LaCrosse Sensoren empfangen lassen.


Noch eine (blöde) Frage: Gab es irgendwelche Präferenzen hinsichtlich der Module und den CC0-CC4 ? Sollte ein 868 Modul an CC0 hängen und erst an CC1 ein 433 ? Oder spielt es (wg. des Images) keine Rolle ?

Vielen Dank!

Gruss

Andreas



Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 Februar 2017, 20:34:17
Zitat von: fhem-challenge am 10 Februar 2017, 19:26:16
Ich erreiche nun CC0=433,CC1=868,CC2=868 korrekt (slowRF). IT empängt mein CC0(433) auch schon.
Slow RF funktioniert nicht an CC2. Funktioniert nur an CC0 und CC1.

Zitat von: fhem-challenge am 10 Februar 2017, 19:26:16
Frage: Ist es als Versorgung besser via VCC an den Pins von X4 zu verwenden, anstelle USB vom STM32  ?... aber das wäre ja nun mal 3,3V ... darüber bekomme ich den W5100 nicht in Betrieb. Vielleicht löte ich die 100nF an die Module und ein 10uF an den W5100. Ich habe leider jetzt mein Oszi nicht dabei.
Die Versorgung muss schon über USB kommen. Ansonsten wird der W5100 nicht versorgt. Der Spannungsregler auf dem Maple Mini ist ausreichend dimensioniert um den STM32 und die Transceiver versorgen zu können. Eventuell ist dein USB Netzteil zu schwach.

Zitat von: fhem-challenge am 10 Februar 2017, 19:26:16
Und wenn ich schon einmal so viel frage, dann gleich noch eine Frage (sorry): Ist im Code auch schon LaCrosse a'la "Nr2" implementiert ? Denn hier würde sich der MapleCUN sehr lohnen (ein RFM69 geht ja nunmal nicht)... ich würde dann einen der vier CC1101 (868) mit "Nr2" meine LaCrosse Sensoren empfangen lassen.


Noch eine (blöde) Frage: Gab es irgendwelche Präferenzen hinsichtlich der Module und den CC0-CC4 ? Sollte ein 868 Modul an CC0 hängen und erst an CC1 ein 433 ? Oder spielt es (wg. des Images) keine Rolle ?
SlowRF funktioniert nur an CC0 und CC1. Nach einem Reset der Konfiguration ist die Frequenz von CC0 auf 868MHz und CC1 auf 433MHz voreingestellt. Lässt sich dann aber auch umkonfigurieren.
KOPP und MBUS funktionieren nur an CC0.
Die restlichen Protokolle sind an allen Transceivern verfügbar.

@locutus
Ich denke, dass ich den Fehler gefunden habe. Teste mal die angehängte Version.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 10 Februar 2017, 20:52:01
Zitat von: Telekatz am 10 Februar 2017, 20:34:17
Slow RF funktioniert nicht an CC2. Funktioniert nur an CC0 und CC1.
Die Versorgung muss schon über USB kommen. Ansonsten wird der W5100 nicht versorgt. Der Spannungsregler auf dem Maple Mini ist ausreichend dimensioniert um den STM32 und die Transceiver versorgen zu können. Eventuell ist dein USB Netzteil zu schwach.
SlowRF funktioniert nur an CC0 und CC1. Nach einem Reset der Konfiguration ist die Frequenz von CC0 auf 868MHz und CC1 auf 433MHz voreingestellt. Lässt sich dann aber auch umkonfigurieren.
KOPP und MBUS funktionieren nur an CC0.
Die restlichen Protokolle sind an allen Transceivern verfügbar.

@locutus
Ich denke, dass ich den Fehler gefunden habe. Teste mal die angehängte Version.


Okay, danke für die schnelle Antwort.

Ich habs mal gemessen, in der Tat brauchen 4 Transceiver und W5100 so um die 250mA.

Blöderweise habe ich kurzerhand auf CC1 auch ein 868 Modul gelötet ... naja, werde ich dann wieder umlöten.

Bei CC2 & CC3 hab ich schon bemerkt, lassen sich nicht in der Frequenz ändern. CC0 & CC1 hingegen schon.


Viele Grüße!

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 11 Februar 2017, 21:05:26
Zitat von: Telekatz am 10 Februar 2017, 20:34:17
@locutus
Ich denke, dass ich den Fehler gefunden habe. Teste mal die angehängte Version.
Du gibst auch nicht so schnell auf?! Das ist es gewesen. Damit funktioniert die HM-MOD-UART am MapleCUN. Woran haperte es? Ich hatte schon mein W5100 Modul verdächtigt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 Februar 2017, 22:48:18
Der Zugriff auf einen nicht initialisierten Pointer des USB Stacks hat den Fehler ausgelöst. Der Pointer wird erst nach dem Anschluss an einen USB Host initialisiert. Da ich meinen MapleCUN bisher immer an einem Rechner angeschlossen hatte und nicht über ein Netzteil, ist mir das bisher nicht aufgefallen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 12 Februar 2017, 07:45:04
Zitat von: fhem-challenge am 10 Februar 2017, 19:26:16
Ich habe den Eindruck, dass es ggf. an der Stabilität von VCC liegt. Ich versorge die ganze Platine mit dem STM32 USB.
Frage: Ist es als Versorgung besser via VCC an den Pins von X4 zu verwenden, anstelle USB vom STM32  ?... aber das wäre ja nun mal 3,3V ...

Bei Zweifeln an der Spannung würde ich erst mal messen ob die 5V wirklich 5V sind.  Die "dicke" des USB Kabels macht hier viel aus. Gute Kabel zum Schnell-Laden sind dicker und haben weniger Widerstand.
Dann würde ich noch einen größeren Kondensator verbauen um Spitzen abzufedern. Die Abblock-Kondensatoren an den Funkmodulen sind nur dazu da um "Störungen kurzzuschliessen",
Und wer  unter dem Bett gerne Alufolie verlegt, der kann ja noch an beliebiger Stelle einen fetten Elko verbauen :-)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 12 Februar 2017, 11:27:47
Zitat von: Ranseyer am 12 Februar 2017, 07:45:04
Bei Zweifeln an der Spannung würde ich erst mal messen ob die 5V wirklich 5V sind.  Die "dicke" des USB Kabels macht hier viel aus. Gute Kabel zum Schnell-Laden sind dicker und haben weniger Widerstand.
Dann würde ich noch einen größeren Kondensator verbauen um Spitzen abzufedern. Die Abblock-Kondensatoren an den Funkmodulen sind nur dazu da um "Störungen kurzzuschliessen",
Und wer  unter dem Bett gerne Alufolie verlegt, der kann ja noch an beliebiger Stelle einen fetten Elko verbauen :-)

ja, hat sich mittlerweile geklärt. Mein Netzteil liefert 5V/2A und ist (gemessen) sehr stabil (ca- 5.02V am STM32 direkt gemessen) ... das Problem tauchte auch nicht mehr auf. Das mit den Kondensatoren ... ja ... weiss ich... Elektronik ist mir zum Glück nicht wirklich fremd :-)

Hatte noch gesehen, das am CC0 die beiden Leitungen fehlten (nachgelötet --> geht)... hatte es erst danach hier im Thread gelesen.

Noch eine Beobachtung:

Wenn ich den MapleCUN aus/einschalte ... habe ich in FHEM kein automatisches reconnect. Alle anderen CUNs/MAXCUbes/HMLANs machen in FHEM ein reconnect. Erst z.b. ein zweifaches "ccconf" "verbindet" den mapleCUN wieder (oder eben auch ein erneutes define ...). Ansonsten läuft der MapleCUN nun auch mit 4 Transceivern seit zwei Tagen gut.

- Etwas problematisch ist die "Lokation" des W5100 ... wenn dieser nur zwei mm weiter weg vom STM32 positioniert wäre, würde das Modul "kopfüber" stabil auf die Platine passen, so überdecken sich die Platinen eben etwa 2mm.

- Die Lötpunkte für etwaige Block Kondensatoren sind etwas zu knapp an den Modulen.

- Die Leiterbahn für die Lötstelle der SMA Buchsen machen an (ich glaube es waren zwei Module) eine kleine "Kurve". Das ist nicht wirklich problematisch, aber auch bei 868MHz schon eine winzige Induktivität. Wenn die Leiterbahn "greade" auf die Buchse zulaufen würde, wäre das ggf. besser.

Frage: Wie lange hatte eigentlich die Lieferung aus China für die PCB's gedauert ?



Viele Grüße!

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 12 Februar 2017, 12:07:55
Zitat von: fhem-challenge am 12 Februar 2017, 11:27:47
Noch eine Beobachtung:

Wenn ich den MapleCUN aus/einschalte ... habe ich in FHEM kein automatisches reconnect. Alle anderen CUNs/MAXCUbes/HMLANs machen in FHEM ein reconnect. Erst z.b. ein zweifaches "ccconf" "verbindet" den mapleCUN wieder (oder eben auch ein erneutes define ...).
Siehe dazu auch: https://forum.fhem.de/index.php/topic,52523.msg443733.html#msg443733
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 12 Februar 2017, 21:43:11
Zitat von: locutus am 12 Februar 2017, 12:07:55
Siehe dazu auch: https://forum.fhem.de/index.php/topic,52523.msg443733.html#msg443733

Okay ja, FHEM bekommt aber bei den CUNO's/HMLANs & MAXCubes recht schnell mit, wenn die mal "weg" waren. Das sehe ich an den "reappeared"... Messages. 2 Stunden ist ja bei TCP das Maximum. In der Praxis bei einem RTT (selbst im WLAN) liegt das timeout ja viel geringer. Wenn FHEM über ein CUNO senden will, dann merkt es schnell, wenn kein Ack. zurück kommt.



Viele Grüße!


Andreas

Titel: Antw:Selbstbau CUN
Beitrag von: Garagenhaus am 15 Februar 2017, 15:57:43
Zitat von: Ranseyer am 01 Februar 2017, 08:56:28
Allerdings warte ich noch auf Feedback um eine zweite Charge anzustossen...
(Beim Feedback geht es mir vor allem um die mechanische Anordnung)
Cooles Projekt! Die mechanische Anordnung mit den Buchsen am äußersten Rand würde ich nicht machen, wenn es nicht unbedingt notwendig ist. Wenn das absolut notwendig wäre müsste man ja so konsequent sein und die Briefmarkenmodule auch entsprechend weit von einander trennen. Bei denen sind es aber nur ~4cm.
Ergo würde ich die Buchsen mehr in die Mitte machen, so dass mechanisch gesehen, die SMA Buchsen der 433 Module aus dem Reichelt Gehäuse rausschauen würden.
Länge der 433 Module 3,2cm x2 = 64mm Innenmaße: 65,5m -> Die Buchsen so mittig wie möglich

Auf einem Testaufbau mit Steckboard müsste man doch ganz gut überprüfen können, ob es praktisch relevant ob der Abstand 4 oder 10cm beträgt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Februar 2017, 16:48:31
Danke für den Hinweis. Ich bin von dem Aufbau den Du beschreibst abgekommen. ...denke nicht dass man Zuhause auf dem Tisch mit unserer Ausrüstung alles komplett testen kann.
Aber wer größere Abstände will, kann auch mit Pigtails arbeiten. (Anlöten oder mit U.FL an den Verbreiterten Pads der SMA-Buchse)
Das würde ca. so aussehen: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Board-V42.png
(Die Unsicherheit ist, dass keine passenden Schrauben für die Montage habe und daher die größe vom Kopf nicht kenne)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 15 Februar 2017, 16:55:05
Hallo,

Zitat von: Telekatz am 10 Februar 2017, 20:34:17
Slow RF funktioniert nicht an CC2. Funktioniert nur an CC0 und CC1.
nur zum Verständnis: dann macht es auch nur bei CC0 und CC1 Sinn, 433 MHz DIL Module vorzuhalten, oder? Weder MAX; M-Bus oder Homematic funktionieren mit 433 MHz.

Danke + Gruß

PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 15 Februar 2017, 17:55:46
Im Prinzip ja, außer jemand implementiert für Somfy auch noch den Empfang. Und die 433 MHz Module gibt es ja auch noch als Briefmarkenmodul mit der selben Belegung wie die 868 Module. Deshalb hab ich jetzt mal eine Platine für vier Briefmarkenmodule entworfen und bestellt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 15 Februar 2017, 18:03:39
Mir scheint, jetzt arbeiten mindestens drei Layouter an dem Projekt :-)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Februar 2017, 19:29:31
Zitat von: Telekatz am 15 Februar 2017, 17:55:46
...die 433 MHz Module gibt es ja auch noch als Briefmarkenmodul mit der selben Belegung wie die 868 Module. Deshalb hab ich jetzt mal eine Platine für vier Briefmarkenmodule entworfen und bestellt.


Guter Ansatz.

Die Steckmodule machen m.E. Sinn für
-Entwickler
-massive Tests
-Bei HW Defekten (keine Ahnung ob mal so ein Modul kaputt ging, und die Stamps kann man mit passender Ausrüstung ja auch gut wechseln)

Die Stamps machen für mich Sinn wegen
- Platz und Kosten
- mechanisch stabil, keinerlei Wackeln...

Daher setze ich* ab sofort vor allem auf die Stamps und wegen LAN auf das teurere aber auch gut steckbare Modul: http://www.usriot.com/p/w5500-modules/

Was mir unklar ist ob es noch "ganz tolle Steckmodule" mit PA, LNA usw. gibt die wirklich Sinn machen. (Und wie viele davon von vier)



*Damit meine ich eine Version die zackig fertig sein soll. Hoffe dass in Ruhe und mit Peters Unterstützung noch eine Mittlere Version zustande kommt...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Februar 2017, 21:04:46
Und noch ne Idee die siehe oben (#115) eingeflossen ist.

Wenn man die Pads für die SMA Buchse minimal verbreitert sollte eine U.FL Buchse einzulöten sein. Daran kann man dann Standard Pigtails (U.FL Stecker, Kabel, SMA-Buchse für Lochmontage) einstöpseln.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 16 Februar 2017, 21:24:42
Hallo locutus,

Zitat von: locutus am 09 Februar 2017, 19:15:47
Inzwischen ist das kompakte W5500 Modul, das ich im November bestellt habe, eingetroffen.
könntest Du bitte Deinen Schaltplan posten (bzw. ggf. habe ich diesen auch übersehen)? Mich interessiert, wofür der rote Schalter ist. Die zwei Buchsenleisten sind für das Kleine W5500 Modul von usriot und die Pinleiste neben dem mapleMini ist vermutlich zum Flashen ...

@Telekatz: Wenn ich das richtig gelesen habe, ist das W5100 Modul standard mäßig mit in der Software, für das W5500 müsste man den Code ändern, richtig?

@Ranseyer: Eine nur 50 mm breite Platine wird ziemlich sportlich werden  ;)

Danke + Gruß

Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 16 Februar 2017, 21:36:27
Ich habe in der board.h ein entsprechendes #define, mit dem man den Wizchip einstellen kann, aufgenommen.

#define _WIZCHIP_      5100

Es wird mit 5500 ohne Fehler kompiliert, aber die erstellte Firmware habe ich nicht getestet.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 18 Februar 2017, 10:15:10
Zitat von: PeMue am 16 Februar 2017, 21:24:42
könntest Du bitte Deinen Schaltplan posten (bzw. ggf. habe ich diesen auch übersehen)? Mich interessiert, wofür der rote Schalter ist. Die zwei Buchsenleisten sind für das Kleine W5500 Modul von usriot und die Pinleiste neben dem mapleMini ist vermutlich zum Flashen ...
Alles soweit richtig erkannt. Der Schalter am BOOT1 dient zur seriellen Programmierung.
Die Gerberdaten sind für ITEAD (https://www.itead.cc/open-pcb/pcb-prototyping/2layer-green-pcb-5cm-x-10cm-max.html).

Zitat von: Telekatz am 16 Februar 2017, 21:36:27
Ich habe in der board.h ein entsprechendes #define, mit dem man den Wizchip einstellen kann, aufgenommen.
Es wird mit 5500 ohne Fehler kompiliert, aber die erstellte Firmware habe ich nicht getestet.
Stellst du bitte den Quellcode zur Verfügung? Danke!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 18 Februar 2017, 11:06:44
Hi, gerade erst gesehen!
Cooles Projekt! Wer hat den noch Testplatinen bzw. wer plant demnächst eine Bestellung? Ich würde gerne mittesten! Hat jemand auch zufällig eine BOM mit Herstellerlinks rumliegen?
Gruß Arnd


Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Februar 2017, 11:18:12
Zitat von: locutus am 18 Februar 2017, 10:15:10
Stellst du bitte den Quellcode zur Verfügung? Danke!
https://github.com/heliflieger/a-culfw/tree/multiCC (https://github.com/heliflieger/a-culfw/tree/multiCC)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 19 Februar 2017, 11:53:15
Hi,
Zitat von: Telekatz am 10 Februar 2017, 20:34:17
SlowRF funktioniert nur an CC0 und CC1. Nach einem Reset der Konfiguration ist die Frequenz von CC0 auf 868MHz und CC1 auf 433MHz voreingestellt. Lässt sich dann aber auch umkonfigurieren.
KOPP und MBUS funktionieren nur an CC0.
Die restlichen Protokolle sind an allen Transceivern verfügbar.
worin besteht denn die Einschränkung auf CC0 und CC1? CC_OUT/GDO0 ist doch auch an CC2 verfügbar.
Kannst Du das vielleicht kurz erläutern?

Danke,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 19 Februar 2017, 13:22:51
Da jeder zusätzliche SlowRF Receiver einiges an Ressourcen benötigt erschien mir einer für 868 MHz und einer für 433 MHz als ausreichend. Theoretisch ist noch ein dritter möglich, aber für mehr gibt es keine freien Timer mehr im STM32.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 19 Februar 2017, 14:28:27
Hi,
danke für die Info.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 19 Februar 2017, 17:05:19
Zitat von: Telekatz am 16 Februar 2017, 21:36:27
Es wird mit 5500 ohne Fehler kompiliert, aber die erstellte Firmware habe ich nicht getestet.

Der Compiler läuft zwar fehlerfrei durch, aber der STM32 kommuniziert nicht korrekt mit dem W5500.
-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Feb 18 2017 12:02:00 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : C0:C0:C0:00:00:00
IP : 0.242.242.242
GW : 0.0.0.0
SN : 0.0.0.255
=======================================
-I- init USB
-I- init Complete
0:TCP server start
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 19 Februar 2017, 17:24:24
Da fehlt noch ein #include in wizchip_conf.h:

diff --git a/culfw/Wiznet/Ethernet/wizchip_conf.h b/culfw/Wiznet/Ethernet/wizchip_conf.h
index 341f868..d204404 100644
--- a/culfw/Wiznet/Ethernet/wizchip_conf.h
+++ b/culfw/Wiznet/Ethernet/wizchip_conf.h
@@ -55,6 +55,7 @@
#define  _WIZCHIP_CONF_H_

#include <stdint.h>
+#include "board.h"
/**
  * @brief Select WIZCHIP.
  * @todo You should select one, \b 5100, \b 5200, \b 5300, \b 5500 or etc. \n\n
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 19 Februar 2017, 18:12:40
Besten Dank! Das sieht gut aus.
Ihr findet im Anhang die Firmware für das W5500 Netzwerkmodul.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 19 Februar 2017, 18:23:11
Danke ! (nun müsste man das Modul nur schon haben :-)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 21 Februar 2017, 23:02:32
Hallo Telekatz,

ich habe mal das MapleCUL.bin auf ein STM32F103C8T6 (BluePill) gebracht. Vom Aufbau ist er etwas anders als ein Maple Mini aber ich habe versucht die GPIO richtig zuzuordnen.
Es ist ein 1. CC1101 (868MHz Briefmarke) und 2. CC1101 (433MHz) angeschlossen.
Auf der DebugUART kommen diese Meldungen (TX/RX A9/A10):

-I- Getting new Started Project --
-I- MapleCUL
-I- Compiled: Feb  9 2017 21:43:13 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init USB
-I- init Complete

Ich konnte auch schon vom 1.CC1101 FS20 Nachrichten empfangen. Aber nicht regelmäßig. Der STM32 ist per USB mit dem Odroid verbunden. Beim reopen von FHEM kommt der Hinweis "Cannot init  /dev/maple" nach mehren Versuchen geht es dann manchmal. Was noch auffällt ist das die Frequenz nicht richtig gesetzt ist. 500 MHZ oder 1600 MHz.

Def.:
defmod mapleCUL CUL /dev/maple@38400 4424
attr mapleCUL rfmode SlowRF
attr mapleCUL room CUL
attr mapleCUL verbose 5

setstate mapleCUL opened
setstate mapleCUL 2017-02-21 22:23:53 ccconf freq:5870.000MHz bWidth:203KHz rAmpl:24dB sens:4dB
setstate mapleCUL 2017-02-21 22:22:04 cmds B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
setstate mapleCUL 2017-02-21 22:36:17 state opened
setstate mapleCUL 2017-02-21 22:35:28 version No answer

der Port wird per udev Rule (99-local.rules) gemappt.

# STMicroelectronics BluePill
ATTRS{idProduct}=="5743", ATTRS{idVendor}=="0483", SYMLINK+="maple", MODE="0666"

Das ganze ist auf einem Steckbrett aufgebaut. Mit dem 1. CC1101 (868MHz Briefmarke) konnte ich schon in einer andersn Schaltung mit einem SignalDuino Daten empfangen. Einen Def. des CC1101 schließe ich aus.
Mit dem STM32 habe ich auch noch keine Erfahrungen. Vielleicht muß ja auch noch ein Bootloader drauf, der den USB-Port bedient ??  Boot0=1 und Boot1= 0 eingestellt. Vielleicht paßt das ja auch nicht.

Vielleicht könntest du mir einen Hinweis geben. Ich hoffe ich habe alles wichtige mitgeteilt. Vielen Dank für deine Zeit und Arbeit.

Jörg
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 21 Februar 2017, 23:40:40
Da der STM32 kein EEPROM hat wird am Ende des Flashspeichers das EEPROM simuliert. Da der STM32F103C8T6 nur 64KB Flash hat, muss die Startpage für das EEPROM in eeprom.c angepasst werden:

#define EE_START        ADDR_FLASH_PAGE_60
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 22 Februar 2017, 00:47:42
Hallo Telekatz,

Danke für die schnelle Antwort. Konnte die MapleCUL neu kompilieren. Geht leider immer noch nicht. Es werden auch wieder die falschen Frequenzen angezeigt.
Mach dann mal morgen weiter.

Jörg
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Februar 2017, 21:14:26
@Telekatz: Ich habe mich mal am Thema 1Wire versucht und festgestellt dass ich davon keine Ahnung habe. (Das soll evtl auch so bleiben, falls RS485 so läuft wie ich will)

Kannst Du mal einen Blick auf die Anlage werfen ob das so passt ? (Spannungen: 3,3 oder 5V vom Maple per Löt-Jumper, oder beliebige extern. SMD-Footprint worauf sicher auch ne Sicherung passen sollte)
URL wie immer: https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large (inkl. Board+ Schematic als PNG)

PS: Ich habe diesen Teil mal lieber hier gepostet...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 27 Februar 2017, 21:31:40
Hi Ranseyer,

was macht R3? Den habe ich den Referenzschaltungen nirgends gesehen...
Den DS9503 finde ich eine gute Idee, sollte man eigentlich viel häufiger einsetzen.

An welche Pins willst Du den damit gehen? An den Arduino oder Pins von einem Radio?

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 27 Februar 2017, 22:35:10
Zitat von: A.Harrenberg am 27 Februar 2017, 21:31:40
was macht R3? Den habe ich den Referenzschaltungen nirgends gesehen...
Den DS9503 finde ich eine gute Idee, sollte man eigentlich viel häufiger einsetzen.
Den hatte ich in meiner Schaltung dafür vorgesehen, falls man den DS9503 nicht verwendet. Ist dann wie beim CUNO verschalten. Kann man mit dem DS9503 weglassen.

Zitat von: A.Harrenberg am 27 Februar 2017, 21:31:40
An welche Pins willst Du den damit gehen? An den Arduino oder Pins von einem Radio?
PB6 und PB7 am Maple.

@Ranseyer
Hab mir gerade nochmal das Datenblatt vom DS9503 angesehen und festgestellt, dass er falsch herum eingebaut ist. 1 muss mit 6 und 2 mit 5 vertauscht werden.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Februar 2017, 22:59:03
Danke, dann wäre das also so korrekt ?
(Komplett im Github)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 27 Februar 2017, 23:05:36
Ich denke ja.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Februar 2017, 23:09:33
Danke !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 28 Februar 2017, 07:43:24
Hi,
Zitat von: Telekatz am 27 Februar 2017, 22:35:10
PB6 und PB7 am Maple.
ok, das wäre dann Radio2 (CC_CS2, CC_IN_2) auf der Platine von Ranseyer.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 28 Februar 2017, 14:36:34
Gehäuse für große Platine gedruckt:

Nun läuft mein MapleCUN schon problemfrei seit 3 Wochen mit 1 x rfmode (868), 1 x rfmode (IT 433), sowie 1 x HM mit dem W5100.

Deshalb habe ich nun den MapleCUN in den Produktivbetrieb genommen und der ersetzt somit (1 x HMLAN, 1 x CUNO , 1 x MaxCUBE (geflashed), 1 x NanoCUL (IT)).

Einzig das Problem mit dem unpassenden Massen der großen Platine brachte mich dazu, ein ein eigenes Gehäuse zu entwickeln/drucken.

Hierbei passt die "große" Platine exakt hinein und der Fehler der Platine mit der ungünstigen Plazierung des W5100 habe ich mit einer speziellen Halterung gelöst, die von unten verschraubt wird. Das Gehäuse sieht ganz gut aus, und hält auch alles zusammen.

Wer sich zufällig auch so ein Gehäuse sich drucken will, und die "große" Platine benutzt (auch ohne eigenem 3D-Drucker ja z.b. tinkercad bestelltbar) --> Anbei meine 3D Files des Gehäuses (habe ich auch bei tinkercad freigegeben --> public)

Ich weiß ja, dass schon neuere Platinenvarianten hier im Thread existieren (ich glaube es sind schon 3 Layouter dabei). Vielleicht mache ich dann ein neues Gehäuse. Aber derzeit läuft das Gesamtsystem wirklich gut, so wie es ist.

Die Aufschrift auf dem Gehäuse lautet "CUNx", weil "MapleCUN" als Aufschrift nicht funktioniert, denn ein "a","e","p" lässt sich im 3D Druck nicht sinnvoll drucken, da die mittleren Teile der Buchstaben kein "Halt" haben.


Viele Grüße!

Andreas


Zu den Files:

MapleCUNcase1 ALL = sind alle drei Bauteile
bottom , top = sind selbst erklärend
W5100 ist die Halterung für den W5100, damit dieser nicht so labil auf der Platine steckt.





Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Februar 2017, 19:39:41
Das sieht cool aus. Glückwunsch !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 28 Februar 2017, 21:38:06
Hallo Telekatz,

vielleicht könntest du mir einmal helfen. Als Anlage der Schaltplan. Schaltung ist auf Steckbrett aufgebaut.
Der STM32 wird mit dem STM32FLASH und der MapleCUL.bin bespielt.
Version: V 1.23.09 a-culfw Build: private build (unknown) MapleCUL (F-Band: 868MHz). Anpassung: eeprom.c
#define EE_START        ADDR_FLASH_PAGE_60

Der CC1101 funktioniert, ich habe Ihn jetzt als SignalDuino 868MHz im Einsatz und er empfängt Daten. Schaltung ebenfalls auf Steckbrett.

Die Frequenz läßt sich nicht einstellen und dadurch wird auch nichts empfangen. Im Linux werden 3 Schnittstellen angelegt (ttyACM0 - 2).
Muß hier noch ein Bootloader installiert werden ?

lsusb -v -s 001:0xx

Bus 001 Device 106: ID 0483:5743 STMicroelectronics
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0         8
  idVendor           0x0483 STMicroelectronics
  idProduct          0x5743
  bcdDevice            2.00
  iManufacturer           1 (error)
  iProduct                2 (error)
  iSerial                 3 (error)
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          207
    bNumInterfaces          6
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         0
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               2 (error)
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         2
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               2 (error)
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          3
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        2
        bSlaveInterface         3
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         4
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       1 AT-commands (v.25ter)
      iFunction               2 (error)
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          5
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        4
        bSlaveInterface         5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        5
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)


Vielen Dank.
Jörg
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Februar 2017, 21:47:03
Ich würde dann gerne das große Board in Richtung final bringen...
-Antennenanschlüsse werde ich noch manuell nacharbeiten (gerade)
-W5500 in der ersten Version ist nicht mehr vorgesehen
-Dafür W5500 zweireihig
-ggf. funktioniert mySensors (Arduino-Pro mini oder Einzelteile)
  -NRF* Funkmodul
  -RS485 per Kabel
-OneWire
Alles nicht gesteste, etwas mehr Beschriftung fehlt noch.

Daher würde ich mich über Feedback freuen bevor die Produktion startet !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 28 Februar 2017, 21:55:21
Zitat von: Ranseyer am 28 Februar 2017, 21:47:03
Daher würde ich mich über Feedback freuen bevor die Produktion startet !
Liegt die aktuelle Version auf github? Ich schau's mir (hoffentlich) morgen mal an ...

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Februar 2017, 21:56:12
Ja klar. Immer auf GitHub.

Gesendet von meinem HTC One_M8 mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Kuzl am 01 März 2017, 08:26:34
Hallo,

ist es denkbar, evtl auch W-Lan-Modul vorzusehen?

Kenn mich da nicht so aus, aber evtl gehts ja sogar mit dem ESP8266
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 01 März 2017, 08:49:17
Zitat von: Kuzl am 01 März 2017, 08:26:34
Hallo,

ist es denkbar, evtl auch W-Lan-Modul vorzusehen?

Kenn mich da nicht so aus, aber evtl gehts ja sogar mit dem ESP8266

Auch aus meiner Sicht keine wirklich schlechte Idee. Ein NRF24... ist ja schon drin (MySensors). Abseits davon hat man aber mit einem ESP8266 noch etwas mehr Flexibilität.

Viele Grüße!

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 01 März 2017, 09:12:30
Ja, einen ESP vorschalten fände ich auch gut.
@Locotus und PeMue: Findet ihr das nicht auch? *lol*
Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 März 2017, 09:50:34
ZitatAuch aus meiner Sicht keine wirklich schlechte Idee. Ein NRF24... ist ja schon drin (MySensors).
Das würde ich nicht so sehen... Irgendjemand (ich) hat ein Projekt mit einem anderen kombiniert. Die beiden haben nichts miteinander zu tun. Somit würde ich z.B. von Telekatz (dessen Thread ist das hier) keinerlei Support zu MySensors erwarten.

ZitatAbseits davon hat man aber mit einem ESP8266 noch etwas mehr Flexibilität.
Einen nackten ESP8266 auf eine große Platine zu packen ist kein Hexenwerk. Das Problem dürfte eher die Softwareunterstützung sein.
Wenn man den MAPLE per USB an einen Rechner anschliesst bekommt man drei neue Devices. Somit müsste der ESP so programmiert werden dass er dies abbildet, dazu müsste der ESP direkt mit zwei zu definierenden Pins des MAPLE verbunden werden (Welche müsste Telekatz sagen). Auch auf dieser Seite wäre sicherlich Aufwand nötig.
Somit hängt es meiner Meinung daran ob jemand diese beiden Sachen programmieren will.

PS: Und eine höhere Bestückungsdichte (bei gleicher Platinengröße) bedeutet auch mehr Vias ... (= z.B. höheres Risiko auf Defekte einer Platine)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 01 März 2017, 18:08:59
Hallo Arnd,

Zitat von: RaspiLED am 01 März 2017, 09:12:30
Ja, einen ESP vorschalten fände ich auch gut.
@locutus und PeMue: Findet ihr das nicht auch? *lol*
ich wüsste jetzt nicht, wie man einen ESP8266 vorschalten sollte. Direkt an USB geht nicht, aber genau da könnte man eine transparent bridge machen. Und nur für die zwei serielle Schnittstellen fände ich das ganze etwas "oversized" ...
Aber vielleicht hat Ranseyer noch eine Idee, wie man das Ding anschließen kann. Ggf. würde ich nur einen ESP8266 ESP01 nehmen.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 01 März 2017, 20:15:13
Hi, ja ich hatte auch an die Transparent Bridge gedacht. Aber Du hast natürlich recht, dann müsste man noch eine Serial zu USB Konverter haben, aber der ESP hat natürlich keinen Host USB ;-)
Da sind wohl nur meine Wünsche und Deine coolen Platinen im Gehirn zusammengetroffen und haben sich zu meinem Post oben verschmolzen *lol*

Aber wir können je fhem2fhem auf einem Raspberry Pi Zero W nehmen und den MapleCUL da dran hängen! Also Kopf hoch ;-)

Gruß Arnd


Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 01 März 2017, 21:27:36
Zitat von: pejonp am 28 Februar 2017, 21:38:06
Hallo Telekatz,

vielleicht könntest du mir einmal helfen. Als Anlage der Schaltplan. Schaltung ist auf Steckbrett aufgebaut.
Der STM32 wird mit dem STM32FLASH und der MapleCUL.bin bespielt.
Version: V 1.23.09 a-culfw Build: private build (unknown) MapleCUL (F-Band: 868MHz). Anpassung: eeprom.c
#define EE_START        ADDR_FLASH_PAGE_60

Der CC1101 funktioniert, ich habe Ihn jetzt als SignalDuino 868MHz im Einsatz und er empfängt Daten. Schaltung ebenfalls auf Steckbrett.

Die Frequenz läßt sich nicht einstellen und dadurch wird auch nichts empfangen. Im Linux werden 3 Schnittstellen angelegt (ttyACM0 - 2).
Muß hier noch ein Bootloader installiert werden ?

Ich hab das mal auf meinem Steckbrett nachgebaut und getestet. Geändert nur die eeprom.c. Boot0=0 und Boot1= 0

Prinzipiell hat es funktioniert und auch etwas empfangen. Da allerdings das Board keine USB Diconnect Schaltung wie der Maple hat, wird ein Reset des Boards nicht vom USB Host erkannt und die USB Verbindung  bleibt stehen. Auch ein reopen hilft dann nicht. Nur ausstecken und wieder einstecken hilft dann.

Zitat von: pejonp am 21 Februar 2017, 23:02:32
der Port wird per udev Rule (99-local.rules) gemappt.

# STMicroelectronics BluePill
ATTRS{idProduct}=="5743", ATTRS{idVendor}=="0483", SYMLINK+="maple", MODE="0666"

Woher weiß udev, welche der drei Schnittstellen gemappt werden soll? Die haben alle drei die selbe Product und Vendor ID. Ich würde /dev/serial/by-path verwenden.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 01 März 2017, 22:48:05
Zitat von: RaspiLED am 01 März 2017, 09:12:30
Ja, einen ESP vorschalten fände ich auch gut.
@Locotus und PeMue: Findet ihr das nicht auch? *lol*
Das STM32 Maple Mini Board ist mit drei seriellen Schnittstellen ausgestattet. Aktuell erfolgt die Kommunikation zwischen MapleCUL und FHEM über USB (MapleCUN über LAN). In der Entwicklungsphase macht es durchaus Sinn USART1 als Debugausgabe zu nutzen. Für künftige Stable Firmware Releases wird Debug zunehmend uninteressanter werden. Deshalb bietet sich die Möglichkeit über USART1 mit FHEM zu kommunizieren. An USART1 könnte jeder erdenkliche serielle zu RS232-, Bluetooth-, LAN-, WLAN-, etc. Wandler mit 3,3V Logik angeschlossen werden.
Ich habe hier nichts zu melden. Der Maintainer hat das letzte Wort.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 März 2017, 22:59:20
ZitatAn USART1 könnte jeder erdenkliche serielle zu RS232-, Bluetooth-, LAN-, WLAN-, etc. Wandler mit 3,3V Logik angeschlossen werden.
Ich habe hier nichts zu melden. Der Maintainer hat das letzte Wort.

Genau. Und um am besten gleich alle drei Devices durchzureichen die am USB Port momentan bereitstehen, wäre sicher noch einiges zu schuften.(??) Und das würde wenige helfen wenn auf der ESP Seite das Gegenstück fehlt.


PS: Vor so ner Spezial-Lösung wäre bestimmt mehr Leuten geholfen wenn man direkt den MAPLE-Bootloader verwenden könnte. Mit dem ist das Flashen absolut geschmeidig. (Im Gegensatz zum HW-Bootloder des STM32)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 März 2017, 23:16:41
Zitat von: Ranseyer am 01 März 2017, 22:59:20
Genau. Und um am besten gleich alle drei Devices durchzureichen die am USB Port momentan bereitstehen, wäre sicher noch einiges zu schuften.(??) Und das würde wenige helfen wenn auf der ESP Seite das Gegenstück fehlt.


PS: Vor so ner Spezial-Lösung wäre bestimmt mehr Leuten geholfen wenn man direkt den MAPLE-Bootloader verwenden könnte. Mit dem ist das Flashen absolut geschmeidig. (Im Gegensatz zum HW-Bootloder des STM32)
Ich habe Mal probiert einen ESP12E auf der nächsten Platine unterzubringen. Das wäre ganz knapp möglich. Aber damit fehlt heftig Platz für das Routing. Das Board ist eh schon überfüllt. Kurz um: derzeit baue ich auf meinem Platinen keinen ESP8266 direkt ein. DBG und zwei UART sind ja herausgeführt. Da kann jeder dran hängen was er will

Gesendet von meinem HTC One_M8 mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 01 März 2017, 23:35:21
Zitat von: Ranseyer am 01 März 2017, 22:59:20
Und um am besten gleich alle drei Devices durchzureichen die am USB Port momentan bereitstehen, wäre sicher noch einiges zu schuften.
Mistverstanden! Alle drei Devices bleiben da, wo sie sind. Stattdessen wird Debug abgeschaltet und zusätzlich zum USB-Port /dev/ttyACM0 werden ausschliesslich CUL RAW Messages über USART1 übermittelt.
Ich hatte das Thema schon mal in Antwort #25 angesprochen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 März 2017, 08:52:48
Zitatzusätzlich zum USB-Port /dev/ttyACM0 werden ausschliesslich CUL RAW Messages über USART1 übermittelt.
Auch gut, falls Telekatz dazu Lust hat... (Dann kann man zwar allen anderen Schnickschnack nicht aus der Ferne nutzen, aber besser als nichts)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Kuzl am 02 März 2017, 09:02:44
Ich hätte eher dran gedacht, dass der ESP8266 vom MAPLE genau so bedient werden, wie die Lan-Interfaces. Also über den ESP (evtl sogar mit der originalen AT-Firmware) einfach die gleichen Ports geöffnet und bedient werden wie sonst über LAN. Man kann evtl auch einen Sketch für den ESP programmieren, sodass er genau so anzusteuern ist wie eines der LAN-Interfaces.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 02 März 2017, 17:35:35
Zitat von: Ranseyer am 02 März 2017, 08:52:48
Auch gut, falls Telekatz dazu Lust hat... (Dann kann man zwar allen anderen Schnickschnack nicht aus der Ferne nutzen, aber besser als nichts)
Ehrlich gesagt hat der ESP8266 jetzt nicht die höchste Priorität bei mir. Die Variante mit der Transparent Bridge wäre jetzt aber noch die einfachste Möglichkeit das zeitnah zu implementieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 März 2017, 23:00:03
Das kann ich gut verstehen.

Daher habe ich mich entschlossen mal etwas siehe Anlage zu machen:
- ESP-03 Modul (was ich noch nie verbaut habe)
- Grundschaltung reicht für den Betrieb + Flashen -oder auch nicht
- Wer die beiden Lotbrücken setzt kann damit dann Stand-Heute evtl. die Debug-Ausgabe von der ersten Seriellen weiterleiten

PS: Falls jemand mit dem ESP-03 Modul Erfahrung hat wär ein kurzer Hinweis nicht verkekrt: Geht / Geht nicht weil...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 03 März 2017, 00:20:16
Ich rate vom ESP-03 ab. Die geringe Speicherkapazität reicht für OTA-Updates nicht aus und die verbaute Patchantenne hat eine miserable Funkreichweite.
Stattdessen empfehle ich ESP-12, 12E oder 12F.
http://jeelabs.org/article/1618a/

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 03 März 2017, 08:05:54
Hallo Ranseyer,

ich würde einen ESP01 nehmen, der hat zwar Durchsteckkontakte (braucht Vorder- und Rückseite im Layout), ist aber sonst relativ platzsparend, da er über der Platine sitzt. Mittlerweile gibt es die auch mit 1MByte Speicher (für OTA). Und für eine transparent bridge reicht das allemal ...

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 03 März 2017, 09:12:58
Schade dass ich meine Meinung zum ESP geändert und ausprobiert habe ob das sinnvoll auf begrenztem Platz machbar ist.
Ich werde es nicht nutzen und schon gar nicht das Steckmodul. (Eine Bridge kann man sicher auch mit einem Kabel flashen falls denn überhaupt ein Update nötig ist)

Aber es scheint ganz gut machbar nach anderen Optimierungen. Daher bleibt der ESP03 erst mal zusätzlich.
Da mir das ganze nicht wichtig ist habe ich mal soweit alles verzichtbare (inkl. Widerlinge) weggelassen.

Anmerkungen ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 03 März 2017, 16:44:26
Ich würde gerne meinen Leidensdruck für den MAPLE Bootloader nochmals erklären...

A) Läuft das Flashen absolut geschmeidig: Flash-Skript starten, MAPLE anstöpseln, warten, fertig !

B) Die Position der Buttons für Reset und Flashen liegen auf der Unterseite des Moduls.
Mir war bisher nicht so bewusst, dass wenn man den Maple fest verlötet (=fast 1 Zerntimeter weniger Höhe und weniger Arbeit), dass man dann an diese Buttons nicht mehr sinnvoll drankommt. Selbst wenn man in eine Platine entsprechende Löcher bohrt wäre das Flashen nur noch wenig spassig.

Wenn man also den Maple fest verlöteten will, geht das m.E. nur sinnvoll wenn man künftig per USB flashen kann :-(

Bonus: Wenn man den MAPLE fest verlötet passt er bei kleinen Gehäusen ggf auch auf die Unterseite der Platine, und wenn man ein hohes LAN Modul direkt daneben hat gibt es viel weniger Konflikte.

Ob ich das selbst gelöst bekomme weiss ich nicht (Hinweise dazu liegen mir vor). Ich habe im Moment nicht einmal eine funktionierende Toolchain weil ich eine andere Kompiler-Version für ein anderes Projekt "nutze".




ed: Die HW-Seitige Umsetzung könnte diesen Thread sprengen. Daher hier: https://forum.fhem.de/index.php/topic,50990.msg598278.html#msg598278
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 03 März 2017, 18:26:56
Nachdem der multiCC Branch mittlerweile in den Master Branch übernommen wurde, schaue ich mir das mal als nächstes an. Trotzdem solltest du dir überlegen, wie du im Notfall auch den Maple Bootloader über den integrierten Bootloader flashen kannst.

Für den MapleCUN gibt es jetzt nur noch zwei verschiedene Firmware Dateien. MapleCUNx4_W5100.bin und MapleCUNx4_W5500.bin, je nach verwendeten Wizchip. Für einen MapleCUL kann mein beide Versionen verwenden. Falls kein Netzwerkmodul angeschlossen ist wird das automatisch erkannt. Auch die Anzahl der Transceivermodule wird automatisch erkannt.

Auch habe ich bei den ARM Modellen die Umschaltung zwischen den RF Protokollen wie hier (https://forum.fhem.de/index.php/topic,11301.0.html) schon einmal vorgeschlagen wurde angepasst. Dies funktioniert mit Ausnahme von KOPP_FC mit allen Protokollen.

Folgende Einschränkungen gibt es für den Betrieb mit mehreren Transceivern:
Die restlichen Protokolle funktionieren an allen Transceivern und auch mehrfach gleichzeitig.

Zitat von: Ranseyer am 03 März 2017, 16:44:26
Ob ich das selbst gelöst bekomme weiss ich nicht (Hinweise dazu liegen mir vor). Ich habe im Moment nicht einmal eine funktionierende Toolchain weil ich eine andere Kompiler-Version für ein anderes Projekt "nutze".
Falls du Eclipse verwendest, kannst du die PATH Variable für jedes Projekt individuell auf deine Toolchain anpassen (Einstellungen->C/C++ Build->Enviroment). Dadurch kannst du auch unterschiedliche Toolchains verwenden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rizzir am 06 März 2017, 10:10:22
Moin moin,

ich muss hier doch erstmal ein Lob an Telekatz und Ranseyer loswerden (und natürlich auch an alle anderen Beteiligten ;) ). Ich bin gestern durch Zufall auf diesen Thread gestoßen und weil ich in meiner Bastelschublade noch ein Maple Mini rumliegen hatte hab ich mal die Schaltung aus dem Wiki auf einem Steckbrett aufgebaut und es hat auf Anhieb tadellos funktioniert.

Ich hatte die Firmware zuerst per ST-Link geflasht aber daraufhin war ich neugierig und habe es mit dem USB-Bootloader (aus dem STM32-Duino Projekt hier (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/STM32F1/binaries)) probiert, was dann leider nicht funktioniert hat. Das Linker-Script hatte ich natürlich angepasst. Ranseyer was hast du denn gemacht, dass es bei dir funktioniert hat und funktioniert es mit der aktuellen Firmware aus der Master-Branch immer noch?

Dann habe ich auch gleich noch probiert eines der Blue-Pill Boards (F103C8T6) zu flashen, da ich von denen auch noch welche rumliegen hatte, was leider auch nicht funktioniert hat. Habe über USB jedenfalls überhaupt keine serielle Verbindung zum Rechner bekommen. Angepasst habe ich da zwar nichts aber wenn dann sollte es auch nur an der Peripherie auf dem Board liegen (LED, Quartz, etc.), wenn es nicht läuft, da der C8T6 genau wie der CBT6 128KB Flash hat und lediglich von ST künstlich gedrosselt (umgelabelt) wird. Die Originalsoftware von ST versagt zwar ihren Dienst wenn man per SWD mehr als 64KB große Programme da drauf schieben möchte aber mit OpenOCD oder anderer Software ist das kein Problem. Dementsprechend sollte es auch kein Problem für eigene EEPROM-Emulatoren sein. Das die C8T6 Boards keine Transistoren für die Reenumeration haben ist mir schon klar aber auch ein ab- und anstecken brachte nichts.

Was das vorhalten von mehreren Toolchains auf einem Rechner angeht benötigt man übrigens auch kein Eclipse um zwischen denen umschalten zu können. Passt man im Makefile die Targets entsprechend so an

MapleCUL:
make TARGET=MapleCUL CC=$(CC) OBJCOPY=$(OBJCOPY) build


dann kann man mit einem einfachen make CC=/path/to/favorite/toolchain/arm-none-eabi-gcc OBJCOPY=/path/to/favorite/toolchain/arm-none-eabi-objcopy MapleCUL einfach die Toolchain seiner Wahl nutzen.

Eine letzte Sache habe ich noch was das Flashen mit internem Bootloader per UART angeht. Es ist wichtig, das man zuerst den Reset-Button loslässt und dann (nach einer Weile, kann beliebig lang sein) erst den anderen Button. Das hat den Grund, dass der STM32 nur dann in den seriellen Bootloader bootet, wenn beim Start der Boot0-Pin auf VCC liegt (was man durch drücken des Buttons erreicht), jedoch überhaupt erst dann bootet wenn der Reset-Pin nicht auf GND liegt (was erst dann passiert wenn man den Reset-Button loslässt). Das sollte gegebenenfalls auch noch im Wiki-Artikel im Abschnitt über das Flashen (https://wiki.fhem.de/wiki/MapleCUN#Flashen) klargestellt werden.

Ich werde mich die Tage auch mal ein bisschen in die Firmware reinfuchsen. Mit der ST-HAL habe ich leider bis jetzt noch gar keine Erfahrung, da ich bisher bei den STM32 entweder direkt auf Registerebene per CMSIS-Header oder mit anderen HALs gearbeitet habe (mbed, ChibiOS). Ich habe jedenfalls auch großes Interesse daran, die Firmware so zu erweitern, dass eine Transparent-Bridge zum Beispiel mit einem ESP8266 mit ESP-Link problemlos möglich ist. Meine Idee wäre dann diese Kombination (STM32, CC1101, ESP8266) in ein kompaktes Gehäuse zu packen und gegebenfalls noch mit einer 1-Wire und einer IR Schnittstelle zu garnieren.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 März 2017, 19:38:32
Der Bootloader für den Maple Mini wird jetzt auch unterstützt. Die Firmwaredateien zum herunterladen sind entsprechend umgestellt worden. Die Anleitung dazu ist in der readme.md vom MapleCUN.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 06 März 2017, 20:31:16
Danke ! Das ist eine sehr gute Nachricht.

Muss es der Bootloader von RogerClarkMelbourne sein, oder darfs auch der originale sein ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rizzir am 06 März 2017, 20:47:38
Ich hatte schon gedacht ich hätte die Bootloader-Option im Makefile und in der Readme übersehen und dann doch festgestellt, dass du es gerade eben noch geändert hast. Also bei mir funktioniert das mit dem STM32Duino Bootloader ganz hervorragend.  :)

Mit dem BL von Maple wird es wohl so nicht klappen:

#define VECT_TAB_OFFSET  0x2000 /*!< Vector Table base offset field.
                                    This value must be a multiple of 0x200. */


beim original Maple ist der Offset 0x5000 und im dfu-util muss man --alt 1 statt --alt 2 wählen. Der Bootloader von Roger Clark Melbourne hat aber eine Kompatiblitätsoption, so dass man wenn man ihn mit -a 1 befeuert sich wie ein Maple-Bootloader verhält. Das kostet zwar die 3kB RAM, die eigentlich eingespart wurden aber wenn man sich die verkneifen kann, wäre eine Kompatibilität mit dem Standard-BL vermutlich schon besser. Für den Otto-Normalverbraucher wäre sicherlich am meisten gewonnen, wenn er gar nicht erst mit dem UART-Bootloader in Berührung käme.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 März 2017, 21:03:55
Man kann den Original Maple Bootloader auch ohne seriellen Bootloader auf die RogerClarkMelbourne Version patchen.
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/maple_mini_bootloaer_updater/maple_mini_bootloaer_updater.ino (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/maple_mini_bootloaer_updater/maple_mini_bootloaer_updater.ino)

Ich lass das jetzt mal so.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rizzir am 06 März 2017, 21:29:47
Wenn du nichts dagegen hast würde ich geschwind Makefile, Linkerscript und Startup-Code anpassen so dass man eine Auswahl hat. In etwa für den Maple-BL

make BOOTLOADER=MAPLE MapleCUL


oder für den STM32Duino-BL


make BOOTLOADER=STM32DUINO MapleCUL


und ohne BL dann


make MapleCUL


ein extra Target für jeden Bootloader wäre vermutlich etwas unübersichtlich.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 März 2017, 22:35:59
Ich will da nicht zu viele Varianten reinbringen. Deshalb nochmal:
Zitat von: Telekatz am 06 März 2017, 21:03:55
Ich lass das jetzt mal so.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 07 März 2017, 12:56:09
Hi,

darf ich als Maple-Neuling mal ein paar dumme Fragen dazu stellen??
Zitat von: Telekatz am 06 März 2017, 21:03:55
Man kann den Original Maple Bootloader auch ohne seriellen Bootloader auf die RogerClarkMelbourne Version patchen.
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/maple_mini_bootloaer_updater/maple_mini_bootloaer_updater.ino (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/maple_mini_bootloaer_updater/maple_mini_bootloaer_updater.ino)
WIE geht das? Mein Verständnis ist das der mitgelieferte Bootloader nicht über die USB-Schnittstelle ansprechbar ist, sondern nur über die interne Serielle... Wie kann man dann ohne diesen Bootloader geflasht zu haben einen Sketch zum patchen hochladen? Jedenfalls kann ich den Maple-mini nicht über den Arduino (1.6.13, Duo-Package + STM32 Package installiert) ansprechen.

Wenn ich mir die Seite von rogerdarkmeldbourne anschaue steht selbst da das man das nur per serieller Schnittstelle machen kann...

Wenn das irgendwie OHNE die serielle gehen würde wäre das cool. Momentan sind meine Maple noch jungfräulich und OHNE Stiftleisten, dann könnte ich mal testweise einen flashen ohne dafür die Stiftleisten einlöten zu müssen. Die würde ich nämlich erst anlöten wollen wenn ich den Zusammenbau auf der Platine mal angeschaut habe um dann je nachdem evtl. längere oder kürze Stiftleisten zu verwenden.

Wäre für eine kurze Mini-Anleitung dankbar.

Danke,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 07 März 2017, 17:13:10
Wie man den Bootloader umbiegen kann, kann ich dir nicht sagen. Das war mir den Aufwand nicht wert.

Für den STM32 Bootloader braucht man  RX+TX, GND wäre auch besser zu haben. VCC auch vom "USB-Wandler" oder Mini-USB am MAPLE.
Also max. 2*2 zusammenhängende Pins. Wenn man also an den beiliegenden Pinleisten nur die 2x2 Pins einlötet bekommt man die super-einfach wieder raus. (Oder halt alle einlöten wenn man dann zufrieden ist)

Das Flashen per STM32-Bootloader mit den Tastern drücken hat bei mir nicht funktioniert (3 MAPLE, einer neu).

Was ganz einfach war:
-Mini-USB halb einstecken
-bot32 gedrückt halten (oder war es Reset?)
-Mini-USB mit der anderen Hand ganz einstecken
-bot32 loslassen

Damit man zeitlich nicht aufpassen muss die übliche Schleife:
Zitat#! /bin/sh
while (true); do

sudo ./stm32flash -w maple_mini_boot20.bin -v /dev/ttyUSB0 #Step 1: Bootloader tauschen
#sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin #Step2:  Firmware per USB
if [ $? -eq 0 ]
then break
fi
sleep 1
done
exit

PS: Ich stelle heute Abend Mal ein paar Fotos rein im anderen Thread. (In der Anlage V1.2 ist noch eine unnötige Nachverdrahtung zwischen GND der beiden UARTs)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 März 2017, 17:33:02
Der STM32F103 hat nur den seriellen Bootloader. Dieser ist im µC integriert und kann auch nicht gelöscht oder überschrieben werden. Um ein komfortables Flashen über USB zu ermöglichen werden die Boards wie die Arduinos mit einem vorinstallierten USB Bootloader ausgeliefert. Dies ist normalerweise der original Maple Bootloader von LeafLabs. Dieser benötigt 16kB Flash und 3kB RAM. Ein "dfu-util --list" liefert bei aktivem Bootloader folgende Meldung:


Found DFU: [1eaf:0003] ver=0201, devnum=8, cfg=1, intf=0, path="1-11.1", alt=1, name="DFU Program FLASH 0x08005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=8, cfg=1, intf=0, path="1-11.1", alt=0, name="DFU Program RAM 0x20000C00", serial="LLM 003"


Daneben gibt es dann den verbesserten STM32duino Bootloader, der lediglich 8kB Flash und kein RAM belegt und auch noch schneller ist.

Der von mir verlinkte Sketch dient nun dazu, aus dem Original Bootloader den STM32duino Bootloader zu machen. Ich hab die kompilierte Version davon mal unten angehängt. Flashen kann man diesen dann mit dem dfu-util:

dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 1 --download maple_mini_bootloaer_updater.bin

Nachdem nach einem Reset der Sketch ausgeführt wird muss man noch eine serielle Konsole zum Maple aufmachen, um die dann erscheinende Sicherheitsabfrage mit Y zu beantworten. Danach wird der STM32duino Bootloader installiert. Ein "dfu-util --list" liefert dann folgende Meldung:

Found DFU: [1eaf:0003] ver=0201, devnum=19, cfg=1, intf=0, path="1-11.1", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=19, cfg=1, intf=0, path="1-11.1", alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=19, cfg=1, intf=0, path="1-11.1", alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"


Siehe dazu auch http://wiki.stm32duino.com/index.php?title=Maple_Mini (http://wiki.stm32duino.com/index.php?title=Maple_Mini)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 07 März 2017, 17:36:51
Hi,
Zitat von: Ranseyer am 07 März 2017, 17:13:10
Wie man den Bootloader umbiegen kann, kann ich dir nicht sagen. Das war mir den Aufwand nicht wert.
ok, dann werde ich wohl doch mal die entsprechenden Pins einlöten. Könnte da natürlich einzelne Pins einlöten, dann wird das entlöten noch einfacher.

Zitat von: Ranseyer am 07 März 2017, 17:13:10
Das Flashen per STM32-Bootloader mit den Tastern drücken hat bei mir nicht funktioniert (3 MAPLE, einer neu).
Hmm, das ist natürlich nicht so schön.

Ich werde das dann mal probieren, mal sehen wie weit ich heute abend komme, ansonsten geht es erst Do/Fr weiter. Muss auch erst noch einen zweiten USB-TTL zusammenlöten, der andere hängt momentan an einer anderen Bastelbaustelle...

Zitat von: Ranseyer am 07 März 2017, 17:13:10
PS: Ich stelle heute Abend Mal ein paar Fotos rein im anderen Thread. (In der Anlage V1.2 ist noch eine unnötige Nachverdrahtung zwischen GND der beiden UARTs)
Das sind ja nur ein paar GNDs...

Danke,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 07 März 2017, 17:53:46
Hi,
Zitat von: Telekatz am 07 März 2017, 17:33:02
Der STM32F103 hat nur den seriellen Bootloader. Dieser ist im µC integriert und kann auch nicht gelöscht oder überschrieben werden. Um ein komfortables Flashen über USB zu ermöglichen werden die Boards wie die Arduinos mit einem vorinstallierten USB Bootloader ausgeliefert. Dies ist normalerweise der original Maple Bootloader von LeafLabs. Dieser benötigt 16kB Flash und 3kB RAM. Ein "dfu-util --list" liefert bei aktivem Bootloader folgende Meldung:
jetzt bin ich noch mehr verwirrt... Das würde ja bedeuten das "normalerweise" bereits der einfache Bootloader drauf ist über den man per USB flashen können sollte, oder?

Wie gesagt hat mein Maple-Mini nicht auf den dfu-util Aufruf unter der Arduino Oberfläche reagiert, dort wurde auch kein Port angezeigt...
Könnte es sein das ich Platinen habe die "nackt" sind und nicht mal den LeafLabs Bootloader drauf haben?

Das von Dir verlinkte Wiki hatte ich schon (mehr oder weniger) gelesen, bin aber nicht ganz schlau draus geworden was nun auf einem neuen Maple nun drauf ist. Das es einen "fest eingebauten" gibt hatte ich schon begriffen.

Ich schau mal das ich heute abend noch mal an und versuche das Ding direkt mit dfu-util auszulesen. Ich gehe davon aus das wenn dort keine Rückmeldung kommt ich keinen LeafLabs Bootloader drauf habe, oder? Werde das mal bis dahin probieren und dann mal die Pins anlöten und darüber probieren...

Dieses "Knöpfchendrücken" ist aber in jedem Fall nötig, oder? Bei dem Aufruf von dfu-util kam etwas in der Art das versucht wird ein Reset per USB auszulösen...

Vielen Dank schon mal für die Infos, werde berichten wie es ausgegangen ist.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stenny73 am 07 März 2017, 18:20:40
Hallo

hört sich gut an das Gerät.

Frage mich gerade ob über die UART Schnittstelle ggf auch ZWave Module alla ZM3102 angeschlossen werden?


stenny
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 März 2017, 19:10:14
Zitat von: A.Harrenberg am 07 März 2017, 17:53:46
Hi,jetzt bin ich noch mehr verwirrt... Das würde ja bedeuten das "normalerweise" bereits der einfache Bootloader drauf ist über den man per USB flashen können sollte, oder?

Wie gesagt hat mein Maple-Mini nicht auf den dfu-util Aufruf unter der Arduino Oberfläche reagiert, dort wurde auch kein Port angezeigt...
Könnte es sein das ich Platinen habe die "nackt" sind und nicht mal den LeafLabs Bootloader drauf haben?
Wenn du den Maple Mini einsteckst und er fängt mit etwa 4Hz zu blinken an, ist das der Maple Bootloader. Als Port wird er auch nicht angezeigt weil DFU eine eigene USB Klasse ist.

Zitat von: A.Harrenberg am 07 März 2017, 17:53:46
Dieses "Knöpfchendrücken" ist aber in jedem Fall nötig, oder? Bei dem Aufruf von dfu-util kam etwas in der Art das versucht wird ein Reset per USB auszulösen...
Das Knöpfchendrücken ist für den fest eingebauten Bootloader nötig.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rizzir am 07 März 2017, 19:13:49
Zitat von: Telekatz am 06 März 2017, 22:35:59
Ich will da nicht zu viele Varianten reinbringen.

Ok, das kann ich verstehen.

Zitat von: A.Harrenberg am 07 März 2017, 17:53:46
Hi,jetzt bin ich noch mehr verwirrt... Das würde ja bedeuten das "normalerweise" bereits der einfache Bootloader drauf ist über den man per USB flashen können sollte, oder?

Ja, aber Bootloader ist nicht gleich Bootloader. Man muss eine Firmware immer an einen Bootloader anpassen. Die Firmware von Telekatz ist momentan für den STM32Duino-Bootloader ausgelegt.

Zitat von: A.Harrenberg am 07 März 2017, 17:53:46
Wie gesagt hat mein Maple-Mini nicht auf den dfu-util Aufruf unter der Arduino Oberfläche reagiert, dort wurde auch kein Port angezeigt...
Könnte es sein das ich Platinen habe die "nackt" sind und nicht mal den LeafLabs Bootloader drauf haben?

Möglich ist alles aber sicher ist auch, dass er den bei mir auch nicht anzeigt, obwohl er trotzdem drauf ist. Denn:

Zitat von: A.Harrenberg am 07 März 2017, 17:53:46
Dieses "Knöpfchendrücken" ist aber in jedem Fall nötig, oder? Bei dem Aufruf von dfu-util kam etwas in der Art das versucht wird ein Reset per USB auszulösen...

Das ist der springende Punkt. Man muss dfu-util unmittelbar nach dem drücken der Reset-Taste auf dem Maple ausführen, weil nur dann der USB-Bootloader für wenige Sekunden aktiv ist, bevor das eigentliche Programm auf dem Maple läuft. Den zweiten Button wie beim flashen per serieller Schnittstelle darfst du allerdings nicht drücken. Das gleiche gilt auch für das Flashen per Arduino (was im Endeffekt auch dfu-util nutzt). Um damit ein Programm mit dem integrierten Bootloader zu flashen musst du es erstmal kompilieren, also oben links auf "Überprüfen" klicken. Dann drückst du den Reset-Button und unmittelbar darauf (am besten innerhalb einer Sekunde) oben links auf "Hochladen". Zum testen ob der drauf ist kannst du entweder "dfu-util -l" in die Konsole eintippen und dann schnell hintereinander Reset-Button und Enter auf der PC-Tastatur drücken oder du kannst auch versuchen ein einfaches Blinky mit der Arduino-IDE zu flashen. War das erfolgreich kannst du per Arduino-Sketch den neuen Bootloader flashen. 
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 März 2017, 19:33:21
Zitat von: rizzir am 07 März 2017, 19:13:49
Das ist der springende Punkt. Man muss dfu-util unmittelbar nach dem drücken der Reset-Taste auf dem Maple ausführen, weil nur dann der USB-Bootloader für wenige Sekunden aktiv ist, bevor das eigentliche Programm auf dem Maple läuft. Den zweiten Button wie beim flashen per serieller Schnittstelle darfst du allerdings nicht drücken. Das gleiche gilt auch für das Flashen per Arduino (was im Endeffekt auch dfu-util nutzt). Um damit ein Programm mit dem integrierten Bootloader zu flashen musst du es erstmal kompilieren, also oben links auf "Überprüfen" klicken. Dann drückst du den Reset-Button und unmittelbar darauf (am besten innerhalb einer Sekunde) oben links auf "Hochladen". Zum testen ob der drauf ist kannst du entweder "dfu-util -l" in die Konsole eintippen und dann schnell hintereinander Reset-Button und Enter auf der PC-Tastatur drücken oder du kannst auch versuchen ein einfaches Blinky mit der Arduino-IDE zu flashen. War das erfolgreich kannst du per Arduino-Sketch den neuen Bootloader flashen. 
Mann kann es auch verhindern, dass der Bootloader automatisch in das geladene Programm springt. Nach einen Reset fängt der Maple erst kurz an schnell zu blinken (ca. 10 Hz). Danach blinkt er langsamer mit etwa 4Hz und nach etwa 2 Sekunden springt der Bootloader zum Hauptprogramm. Wenn man nach dem loslassen des Resetknopfes, währen er mit 10Hz blinkt, den anderen Knopf gedrückt hält bis er langsamer blinkt, bleibt er im Bootloader Modus. Dann hat man genügend Zeit das dfu-util zu starten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 07 März 2017, 20:37:23
ZitatWenn man nach dem loslassen des Resetknopfes, währen er mit 10Hz blinkt, den anderen Knopf gedrückt hält bis er langsamer blinkt, bleibt er im Bootloader Modus. Dann hat man genügend Zeit das dfu-util zu starten.

Evtl ist genau das der Trick... (Wobei ich den zweiten Knopf auch schon etwas länger gedrückt habe)
Fakt ist wer kein so gutes Timing hat kommt mit dem von mir oben beschriebenen Weg auch zum Ziel.


Jedenfalls wollte ich nochmals "Danke" sagen für das super Projekt und die Unterstützung eines Bootloaders. Zwar wäre mir "der schlechtere, aber vorhandene" persönlich lieber gewesen. Aber aus Support-Sicht ist es vermutlich am besten nur einen zu unterstützen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 07 März 2017, 22:43:57
Hallo,

vielen Dank schon mal für die vielen Rückmeldungen, leider klappt es immer noch nicht...

Zitat von: Telekatz am 07 März 2017, 19:10:14
Wenn du den Maple Mini einsteckst und er fängt mit etwa 4Hz zu blinken an, ist das der Maple Bootloader.
Er blinkt mit ca. 4Hz...

Zitat von: rizzir am 07 März 2017, 19:13:49
Ja, aber Bootloader ist nicht gleich Bootloader. Man muss eine Firmware immer an einen Bootloader anpassen. Die Firmware von Telekatz ist momentan für den STM32Duino-Bootloader ausgelegt.
soweit komme ich ja erst gar nicht...

Zitat von: rizzir am 07 März 2017, 19:13:49
Zum testen ob der drauf ist kannst du entweder "dfu-util -l" in die Konsole eintippen und dann schnell hintereinander Reset-Button und Enter auf der PC-Tastatur drücken oder du kannst auch versuchen ein einfaches Blinky mit der Arduino-IDE zu flashen. War das erfolgreich kannst du per Arduino-Sketch den neuen Bootloader flashen. 
Genau das funktioniert ja alles nicht... dfu-util -l sagt bestenfalls "Cannot open DFU device 1eaf:0003", die meiste Zeit aber gar nicht mal das. Demenstprechend kann ich auch unter der Arduino-IDE nicht mal ein einfaches Blink hochladen.

Momentan habe ich das noch alles an dem Windowsrechner (Win10, 64bit), Problem ist das meine Linux-Maschinen alle virtuell sind und es da mit den USB-Ports meist auch Ärger gibt...

An einen Maple habe ich jetzt auch mal RX1/TX1 (und GND/3V3) angeschlossen. Dieser Flash Loader Demonstrator findet da aber auch nie was (und ja, ich habe die RESET+BTN gedrückt, dann erst RESET gelöst, und als letztes BTN).

Na ja, jetzt muss das erst mal bis Do oder Freitag warten und dann werde ich mal versuchen das doch unter Linux  ans laufen zu kriegen.

Trotzdem noch mal Danke an alle,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 07 März 2017, 22:53:10
Hallo nochmal,

ARGH!

Jetzt geht es. Beim Installieren der USB-Treiber ist wohl irgendwie schief gegangen, hatte jetzt noch mal kontrolliert und nachdem ich den Treiber jetzt noch mal neu installiert habe wird das Ding auch von der Arduino-IDE erkannt und ich konnte mal einen BLINK Sketch hochladen. Jetzt gibt es auch einen Com-Port.

Ok, sorry für das Durcheinander und Asche auf mein Haupt. Bin mir aber nicht bewusst das es beim ersten Installieren irgendeine Fehlermeldung gegegen hätte, das Gerät wurde auch als Maple angezeigt, allerdings mit dem Ausrufezeichen...

Jetzt muss ich nur noch rausfinden ob das mit dem Treiber auch den seriellen Bootloader mit dem Flash Loader Demonstrator gestört hat.

Na dann kann ich ja jetzt mal den Bootloader aktualisieren und testweise schon mal die Firmware flashen ,-)

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 07 März 2017, 23:20:55
Und noch mal...

Ist anscheinend nicht mein Tag heute  :(
Wenn man dann auch noch Boot1 WIRKLICH mit GND verbindet und nicht lose rumliegen lässt dann geht auch der Flash Loader Demonstrator.  ;)

So, aber jetzt muss der Rest wirklich bis Donnerstag warten.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rizzir am 07 März 2017, 23:29:28
Zitat von: Telekatz am 07 März 2017, 19:33:21
Mann kann es auch verhindern, dass der Bootloader automatisch in das geladene Programm springt. Nach einen Reset fängt der Maple erst kurz an schnell zu blinken (ca. 10 Hz). Danach blinkt er langsamer mit etwa 4Hz und nach etwa 2 Sekunden springt der Bootloader zum Hauptprogramm. Wenn man nach dem loslassen des Resetknopfes, währen er mit 10Hz blinkt, den anderen Knopf gedrückt hält bis er langsamer blinkt, bleibt er im Bootloader Modus. Dann hat man genügend Zeit das dfu-util zu starten.

Cool, das wusste ich noch nicht. Ist aber definitiv entspannter so ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 11 März 2017, 16:11:09
Hallo,


jetzt hab ich bei den Firmwares den Überblick verloren.

Ich betreibe einen MapleCUN mit 4 Transceivern mit der Firmware

https://forum.fhem.de/index.php/topic,60458.msg573491.html#msg573491

... die funktioniert problemlos.

Welche Firmware ist denn für den multiCC mit eben mehreren Transceivern  (W5100 sowie W5500) lauffähig ?

Die binaries hier ...

https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw

(MapleCUN )

... kann ich zwar erfolgreich flashen, aber am USB Port bekomme ich dann anschliessen keine Verbindung (kein USB Device).


Den ...

https://github.com/heliflieger/a-culfw/tree/multiCC

... gibts ja nicht mehr.



Extrem verwirrend ...


Viele Grüße!

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 11 März 2017, 17:44:50
Hi,

also ich habe gerade erst gestern und heute die CUN4x Firmware geflasht (aus dem Zip in Deinem Link) und es funktioniert...

Allerdings hatte ich bei einer Platine erheblichen Ärger mit dem Bootloader...

Gruß,
Andreas.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 März 2017, 17:49:21
Die Anzahl der Transceiver wird nun automatisch erkannt. Ebenso ob ein Netzwerkmodul angeschlossen ist. Falls man eins angeschlossen hat, muss man die entsprechende Firmware auswählen. Ist keins angeschlossen, dann ist das egal. Es funktionieren beide bei einem MapleCUL .

Allerding habe ich die Firmware für die Verwendung mit einem Bootloader erstellt. Wenn du sie wie bisher geflasht  hast, funktioniert es nicht. Wie du den Bootloader installierst steht in der readme (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md).
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 11 März 2017, 19:07:28
Zitat von: Telekatz am 11 März 2017, 17:49:21
Die Anzahl der Transceiver wird nun automatisch erkannt. Ebenso ob ein Netzwerkmodul angeschlossen ist. Falls man eins angeschlossen hat, muss man die entsprechende Firmware auswählen. Ist keins angeschlossen, dann ist das egal. Es funktionieren beide bei einem MapleCUL .

Allerding habe ich die Firmware für die Verwendung mit einem Bootloader erstellt. Wenn du sie wie bisher geflasht  hast, funktioniert es nicht. Wie du den Bootloader installierst steht in der readme (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md).

Ja.

Also den bootloader zuerst ...
    maple_mini_boot20.bin ??

Mein dfu-util hat Probleme mit 1eaf:0003:

dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Cannot open DFU device 1eaf:0003
No DFU capable USB device available



Habe Treiber neu in Win10 installiert ... dennoch:

dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Cannot claim interface


Ich habe hier derzeit leider nur WIn10 (64) . Meine Linux Systeme sind nicht hier (vor Ort).

Klappt das Flashen mit dfu-util überhaupt korrekt mit win10 (64) ? Ist es jemandem geglückt ?


Viele Grüße!


Andreas


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 März 2017, 20:33:24
Zitat von: fhem-challenge am 11 März 2017, 19:07:28
Klappt das Flashen mit dfu-util überhaupt korrekt mit win10 (64) ? Ist es jemandem geglückt ?
Ja, mir.

Was kommt denn bei
dfu-util --list

Taucht ein Gerät "Maple DFU" überhaupt im Geräte-Manager auf?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 11 März 2017, 20:35:34
Zitat von: Telekatz am 11 März 2017, 20:33:24
Ja, mir.

Was kommt denn bei
dfu-util --list

Taucht ein Gerät "Maple DFU" überhaupt im Geräte-Manager auf?

Ja, siehe Attached.


dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Deducing device DFU version from functional descriptor length
Cannot open DFU device 05ac:8215
Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="2-1.4", alt=2, name="UNKNOWN", serial="UNKNOWN"
Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="2-1.4", alt=1, name="UNKNOWN", serial="UNKNOWN"
Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="2-1.4", alt=0, name="UNKNOWN", serial="UNKNOWN"



und ich bekomme beim FlashVersuch:

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Cannot claim interface

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 März 2017, 20:55:29
Installiere mal den Treiber wie hier beschrieben:
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation (https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation)

Die Dateien dazu gibt es hier:
https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/drivers (https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/drivers)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 11 März 2017, 20:58:22
Alternativ: Keine Treiber brauchst Du unter Linux (was ja auf den Singleboard-Computern meist eh schon läuft)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 11 März 2017, 20:58:56
Zitat von: Telekatz am 11 März 2017, 20:55:29
Installiere mal den Treiber wie hier beschrieben:
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation (https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation)

Die Dateien dazu gibt es hier:
https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/drivers (https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/drivers)


ja, probiere ich auch noch.


ich habe nun deutlich mehr erfolg.


NUR! diese Treiberinstallation für den 1eaf:0003 brachte Erfolg und ich konnte in der Folge nun auch mit dfu-util ... flashen.

http://zadig.akeo.ie/downloads/zadig_2.2.exe


Vielen Dank!


Ggf. ist es sinnvoll ein HowTo zusammen zu fassen, weil es unendliche Variationen gibt und man sich mühsam durchwerkeln muss.

Gruss

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 11 März 2017, 21:02:55
Zitat von: Ranseyer am 11 März 2017, 20:58:22
Alternativ: Keine Treiber brauchst Du unter Linux (was ja auf den Singleboard-Computern meist eh schon läuft)

Klar, i.d.R. läuft bei mir 99% via LINUX. Nur gerade bin ich nicht zuhause und habe nur mein WIN 10 Laptop hier und Zeit zum Flashen ;-)

Viele Grüße!

Andreas

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 11 März 2017, 22:17:10
Hallo,


es ist heute kein guter Tag .. ich werde es für heute mal sein lassen --> giveup.


Nachdem ich nun durch alle Fallen durch bin (dachte ich), läuft nun der W5100 mit der Firmware MapleCUN vom 6.3. (github) nicht MapleCUNx4_W5100_BL.bin.

Am debugPort bekomme ich:

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar  6 2017 18:53:31 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x14
-I- Detected CC2: PN 0x00  VER 0x14
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Not detected ethernet
-I- init USB
-I- init Complete



Verrückt ist, dass die (alte) Firmware: aus ...

https://forum.fhem.de/index.php/topic,60458.msg573491.html#msg573491

... funktioniert, mit genau dem gleichen Board und W5100.

Die COnfig des MapleCUN mit: Wia,Win,Wig etc. funktionieren alle (auch Wid00) ... und dennoch sehe ich im Netz nicht die IP (oder MAC) des MapleCUN.

Nehme ich die alte Firmware, geht es , bei exakte gleicher Hardware und! gleichem STM32.

Was könnte das denn noch sein ?

Hinweis: Ich habe noch die alte/erste Version des PCB. Hat sich am Schaltplan diesbezüglich etwas geändert, dass der W5100 an der alten Platine nicht mehr mit der neuen Firmware läuft ???

Viele Grüße!

Andreas

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: zentis666 am 11 März 2017, 22:31:30
Hi!
Ich versuche mich auch gerade an der Bootloader-Thematik, mit a-culfw_1.23.09_build_195 hatte ich den Maple schon mal als CUL mit dem großen Board am laufen, wollte nun ein 5100er Netzwerkinterface dranhängen und die a-culfw_1.24.01_build_205 neu flashen aber aus irgendeinem Grund läuft dfu-util nicht bis zum Ende.
Was hab ich gemacht:
1. Treiber-Installation wie beschrieben.
2. per Flash Loader Demonstrator die Datei "maple_mini_boot20.bin" geflasht --> hat funktioniert
3. per dfu-util "maple_mini_bootloaer_updater.bin" geflasht, läuft nicht durch
C:\Users\sven\Downloads\dfu-util-0.9-win64>dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 1 --download maple_mini_bootloaer_updater.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [======================== ]  98%        24860 bytesError sending completion packet


dfu-util --list wirft folgendes aus:

C:\Users\sven\Downloads\dfu-util-0.9-win64>dfu-util --list
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="1-1.4", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="1-1.4", alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="1-1.4", alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"


Jetzt kann ich per dfu-util nichts mehr flashen, läuft alles nicht bis 100%.
Wenn ich dann "maple_mini_bootloaer_updater.bin" oder "MapleCUNx4_W5100_BL.bin" per Flash Loader Demonstrator flashe, macht der Maple gar nichts mehr.
Wenn ich "maple_mini_boot20.bin" per Flash Loader Demonstrator flashe kann ich zwar wieder per dfu-util flashen, das läuft aber weder bei  "maple_mini_bootloaer_updater.bin" oder "MapleCUNx4_W5100_BL.bin" zu 100% durch.

Das Ganze unter Windows 10 64. Was mach ich falsch? Liegt das an Windows?

@fhem-challenge: mit der a-culfw_1.24.01_build_205 läuft bei mir ein zweiter Aufbau mit W5100 auch nicht, Netzwerk wird nicht erkannt, im Netzwerk ist er nicht sichtbar (feste IP und DHCP gehen beide nicht) per USB läuft das Ding aber prima (4er Platine, V1.1)

Gruß
Sven
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 März 2017, 22:41:46
Mach einfach mal einen Reset. Bis auf 100% läuft das bei mir auch nie. Funktioniert aber trotzdem.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 11 März 2017, 22:45:37
Hi,
Zitat von: stenny73 am 07 März 2017, 18:20:40
Frage mich gerade ob über die UART Schnittstelle ggf auch ZWave Module alla ZM3102 angeschlossen werden?
na so ein ZM3102 ist schon uralt und eigentlich auch nirgends wirklich zu bekommen.

Ich habe mir es Razberry2 gekauft den ich an einen UART anschliessen wollte. Habe die Teil zwar jetzt hier, bin aber noch nicht dazu gekommen das auszuprobieren. Wird diese Woche auch knapp und dann bin ich 2 Wochen in Urlaub. Aber ich gehe davon aus das das funktioniert, ebenso wie der HMUART den ich an die andere UART klemmen will ,-)

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: zentis666 am 11 März 2017, 22:47:46
Zitat von: Telekatz am 11 März 2017, 22:41:46
Mach einfach mal einen Reset. Bis auf 100% läuft das bei mir auch nie. Funktioniert aber trotzdem.

Danke für diesen wichtigen Hinweis  ;D
Ich dachte schon das Teil ist defekt...

Läuft bei Euch der W5100 mit a-culfw_1.24.01_build_205?
Entweder hab ich falsch verkabelt oder es liegt an der a-culfw...

Gruß
Sven
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 11 März 2017, 23:02:58
Hi,
Zitat von: zentis666 am 11 März 2017, 22:47:46
Danke für diesen wichtigen Hinweis  ;D
Ich dachte schon das Teil ist defekt...
solche Probleme hatte ich gestern und heute auch... ,-(
Bei mir läuft dfu-util auch nicht bis zum Ende durch, zwei Platinen laufen aber.

Zitat von: zentis666 am 11 März 2017, 22:47:46
Läuft bei Euch der W5100 mit a-culfw_1.24.01_build_205?
Entweder hab ich falsch verkabelt oder es liegt an der a-culfw...
Also ich habe gestern/heute zwei von den Platinen aufgebaut und bei beiden heute (je) ein W5100 Modul in Betrieb genommen. Ich habe allerdings eine V1.2 Platine. Ich habe das per Flachband angesteck und es lief (bis auf die Probleme beim flashen) auf Anhieb. Benutzt habe ich genau die von Dir genannte Version.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 12 März 2017, 07:39:33
Moin, bei den Maple kenne ich mich noch nicht aus (China liefert immer noch ;-) Aber wenn ich bei Arduinos diese Probleme habe, hat mir schon häufig eine weitere Spannungsversorgung geholfen. Typischerweise reicht eine zweite USB Buchse als weitere Stromversorgung aus (z.B. Via CP2101 Adapter nur GND und VCC an den USB Port verbinden).
Daher meine Frage: Wie versorgt ihr mit Strom?
Gruß Arnd


Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 12 März 2017, 08:33:53
Hi,

ich hatte den Maple während des Flashens entweder am Rechner oder an einem 2A Netzteil, Spannungsversorgung würde ich da als Ursache eigentlich ausschliessen.

Ich werde gleich mal einen über den Arduino-Updater-Sketch mit dem Bootloader flashen und dann die Firmware per dfu-util hochladen, und mal genauer darauf achten was passiert.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: zentis666 am 12 März 2017, 10:12:02
Hallo,
ich nutze entweder einen USB 2.0 oder USB 3.0 Anschluss am Rechner zum flashen, im Betrieb momentan testweise die USB 2.0 Buchse von nem Intel NUC, bisher hatte ich keine Probleme im Betrieb. Ich denke die Stromversorgung ist relativ unkritisch

Gruß
Sven


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 12 März 2017, 10:43:39
Hi,

so, habe noch mal an einem dritten Maple die ganze Prozedur nachgestellt. Die Toolkette ist mMn nicht wirklich stabil... ;-(

Arduino 1.6.13 mit dem DUE Paket aus dem Arduino Boardmanager und dem STM32 Paket (https://github.com/rogerclarkmelbourne/Arduino_STM32/archive/master.zip) von Roger Clark Melbourne installiert. Die DFU/Seriell Treiber aus dem STM32 Paket installiert.

Ein neuer Maple meldet sich per dfu so:
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=0, name="DFU Program RAM 0x20000C00"
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"


Dann den Bootloader-Updater-Sketch (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/maple_mini_bootloaer_updater/maple_mini_bootloaer_updater.ino) von Roger Clark Melbourne im Arduino kompiliert und hochgeladen. Seriellen Monitor aufmachen und dort "Y" senden. Nach erfolgreichem Update einen Reset am Maple gemacht.

Dann die Ernüchterung, dfu-util kann nicht mehr auf den Maple zugreifen. Nach erneutem Aufruf behauptet mein Windows sogar es könne das Programm gar nicht ausführen und ich solle eine "geeignete" Version beim Softwarehersteller erfragen... Wie gesagt, 2 Minuten vorher ging das noch!

Ich habe dann das STM32 Paket noch mal neu entzippt und über alles drüberkopiert. Danach ging dann dfu-util -l wieder:
f:\Portable_Programme\arduino-1.6.13\hardware\Arduino_STM32-master\tools\win>dfu-util.exe -l
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=0, name=""
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000"
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000"


Dann den Maple in den Bootmodus gesetzt (Reset drücken/loslassen, danach solange der Maple noch schnell blinkt BTN drücken und festhalten bis er langsamer blinkt -> Maple bleibt im Bootmodus).

Danach "dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin" aufgerufen -> dfu-util stürzt ab -> Windowsfehlermeldung "dfu-util.exe funktioniert nicht mehr"...  >:(
Im Tools-Verzeichnis gibt es noch ein weiteres Unterverzeichnis "dfu-util-0.9-win64", da ich ein Win64 habe also das ausprobiert. Flashvorgang startet, läuft aber NICHT bis zum Ende durch sondern es gibt einen Error bei 96%!

f:\Portable_Programme\arduino-1.6.13\hardware\Arduino_STM32-master\tools\win>dfu-util-0.9-win64\dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [======================== ]  96%        57344 bytesError sending completion packet


Aber das Ding scheint zu laufen. Nach einem Reset habe ich drei Serielle Schnittstellen und die LED blinkt ganz normal.

Die Win64 Version von dfu-util liest den Bootloader auch etwas unterschiedlich zu der normalen version aus:
f:\Portable_Programme\arduino-1.6.13\hardware\Arduino_STM32-master\tools\win>dfu-util-0.9-win64\dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [1eaf:0003] ver=0201, devnum=3, cfg=1, intf=0, path="1-1.4", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=3, cfg=1, intf=0, path="1-1.4", alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=3, cfg=1, intf=0, path="1-1.4", alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"


Mein Fazit, es geht, aber zumindest bei mir ist der Ablauf alles andere als logisch. Warum dfu-util zwischendurch meint es geht gar nicht mehr oder warum das Ganze dann bei 96% abbricht hinterlässt bei mir einige Fragezeichen.

Eines der Fragezeichen wäre welches dfu-util (aus welechem Pfad) verwendet die Arduino-IDE dann eigentlich?

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 12 März 2017, 10:53:06
Ahh OK, du nutzt Variante 3:

1) Firmware die nicht nür Bootloader gebaut ist direkt seriell flashen
2) Firmware per USB passend zu vorhandenem USB Bootloader flashen
3) USB Bootloader per USB-umbiegen zu anderem Stand und dann per USB flashen


Variante 3 ist die komplizierteste und somit am fehlerträchtigsten. (Ich nutze die deshalb nicht)
Mir wäre lieber gewesen den schlechteren, aber originalen MAPLE-USB Bootloader zu nutzen. Aber ich kann nicht abschätzen ob damit irgendwann mal der Speicherplatz knapp wird bei neuen Versionen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 12 März 2017, 11:10:34
Hi,

ja mag sein das es die komplizierteste ist, aber nach meinem bisherigen Kenntnisstand doch die einzige Möglichkeit wenn man den Bootloader nicht per seriellem Bootloader updaten möchte.
Man muss den Bootloader ja auf jeden Fall upgraden, und das geht soweit ich weiss nur per Flash Loader / stm32flash über die serielle oder eben über den Updater-Sketch.

Sooo kompliziert finde ich die Vorgehensweise jetzt aber auch nicht, Hauptproblem an der Geschichte scheint mir dfu-util zu sein. Mag sein das es unter Linux besser läuft, ich habe nur keine native Linux-Maschine hier, das sind alles virtuelle und da ist das mit den USB Schnittstellen auch nicht immer so problemlos.

Ich werde das aber vielleicht doch mal unter Linux probieren und schauen ob dort das flashen mit dfu-util ohne Fehler bis zu Ende läuft.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 12 März 2017, 11:30:02
Ja das ist korrekt, wer nur per USB flashen will kann nur:
-es so machen wie du schreibst
-sich selbst die FW kompilieren passend zum Original MAPLE Bootloader (kann ich nicht sagen was exakt zu ändern wäre)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 12 März 2017, 12:44:42
The never never never ending story...

nachdem ich nun die firmware vom 6.3.2017 geflashed habe, und! er nun endlich wieder den W5100 erkennt, lässt sich der MapleCUN nicht wirklich in FHEM instalieren.

define mapleCUN1 CUL 192.168.100.218:2323 3442 ... funktioniert

ein ccconf zeigt auch alle zu erwartenden Parameter korrekt. Und er ist auch erreichbar.

define mapleCUN2 STACKABLE_CC mapleCUN1

... funktioniert hingegen nicht.

2017.03.12 12:33:27 3: Opening mapleCUN1 device 192.168.100.218:2323
2017.03.12 12:33:29 3: mapleCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz
2017.03.12 12:33:29 3: mapleCUN1 device opened
<<<ab hier wurde der zewite stackable definiert >>>
2017.03.12 12:35:39 2: mapleCUN2: unknown message  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
2017.03.12 12:35:42 2: mapleCUN2: unknown message  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
2017.03.12 12:35:45 2: mapleCUN2: unknown message  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
<<<hier der Versuch eines ccconf des zweiten >>>
2017.03.12 12:35:59 2: mapleCUN2: unknown message  (*C0D is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z


und Debugausgabe sagt, er würde drei CC1101 finden und 2323,2324,2325 TCP binden.

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar  6 2017 18:53:31 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:16:D4:95
IP : 192.168.100.218
GW : 192.168.100.254
SN : 255.255.255.0
=======================================
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x14
-I- Detected CC2: PN 0x00  VER 0x14
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Detected ethernet
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]


Macht er aber nicht (siehe nmap).

Hinweis: Ich habe drei CC1101 auf der Platine. Stecke ich den MapleMini mit der uralten Firmware auf die Platinen, geht alles sofort. Stecke ich den MapleMini mit der Version: MapleCUNx4_W5100_BL.bin (6.3.2017) drauf, lässt sich nur! ein CC1101 installieren.

Am USB sehe ich auch drei Schnittstellen.

Da ich leider den MapleCUN schon produktiv habe, und ich meine CUNO's sowie MaxCubes (geflashed) weggestellt hatte, muss ich also bei der UraltFirmware zunächst bleiben, die hatte wochenlang gut funktiniert.

Nach meiner Wahrnehmung sollte doch ...

MapleCUNx4_W5100_BL.bin --> die CC1101 Module erkennen ?
MapleCUNx4_W5100_BL.bin --> den W5100 (oder W5500) erkennen (das macht er ja nun auch mittlerweile) ?


Nachtrag:

und, wie zu erwarten war, ist nur TCP:2323 erreichbar:

root@fhem:~# nmap -sT 192.168.100.218

Starting Nmap 6.47 ( http://nmap.org ) at 2017-03-12 12:50 CET
Nmap scan report for 192.168.100.218
Host is up (0.00016s latency).
Not shown: 999 filtered ports
PORT     STATE SERVICE
2323/tcp open  3d-nfsd
MAC Address: 00:80:41:16:D4:95 (VEB Kombinat Robotron)

Nmap done: 1 IP address (1 host up) scanned in 18.24 seconds


(off topic: witzig finde ich die Vendor Zuordnung für den MapleCUN: MAC Address: 00:80:41:16:D4:95 (VEB Kombinat Robotron)) ... ich denke mir demnächst eine andere MAC address aus ;-)



Derzeit gehen mir die Ideen aus, was es noch sein könnte :-(

Viele Grüße!


Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 12 März 2017, 14:33:43
Hallo Andreas,

Irgendwie sieht es so aus als ob da ein "*" zu viel in den Kommandos drin stecken würde.

Hast Du vielleicht noch irgendwo eine "Leiche" gestackt?? Also etwas das sich auch auf den mapleCUN1 stacken will oder bereits hat? Ich würde mal bei "unsorted"/"everything" suchen ob da nicht vielleicht noch was anderes aktiv ist.

Was passiert denn wenn Du das ganze mal mit ganz neuen Namen machst?

Ich habe mit der Firmware hier jetzt zwei Platinen gebaut die 3x868 haben, allerdings auf CC1, CC2, CC3, CC0 ist momentan "leer", bei einer Platine war da aber auch schon ein 433 Modul drauf und hat funktioniert. Getestet habe ich das ganze aber nur ganz kurz als Homematic.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 12 März 2017, 15:00:55
Zitat von: A.Harrenberg am 12 März 2017, 14:33:43
Hallo Andreas,

Irgendwie sieht es so aus als ob da ein "*" zu viel in den Kommandos drin stecken würde.

Hast Du vielleicht noch irgendwo eine "Leiche" gestackt?? Also etwas das sich auch auf den mapleCUN1 stacken will oder bereits hat? Ich würde mal bei "unsorted"/"everything" suchen ob da nicht vielleicht noch was anderes aktiv ist.

Was passiert denn wenn Du das ganze mal mit ganz neuen Namen machst?

Ich habe mit der Firmware hier jetzt zwei Platinen gebaut die 3x868 haben, allerdings auf CC1, CC2, CC3, CC0 ist momentan "leer", bei einer Platine war da aber auch schon ein 433 Modul drauf und hat funktioniert. Getestet habe ich das ganze aber nur ganz kurz als Homematic.

Gruß,
Andreas.


Hi Andreas,


nein keine Leiche. Ich habe zum Test auch ein neues/nacktes FHEM laufen.

Erklären würde es auch nciht, dass ich mit "nmap" keinen Port sehe, d.h. dass lediglich 2323 gebunden wird, aber die anderen CC1101 mit 2324,2325 ... nicht.

Das wäre ja unabhängig vom FHEM.

Ich habe hier recht unstabile Variationen. Nur und einzig die UraltFirmware läuft extrem stabil (man gut, das ich die hier noch habe). Die ...W5100_BL läuft bei mir auch auf zwei STM32, aber recht instabil.

Ich habe nun einmal die Spannung an dem W5100 gemessen. Die liegt mit 4.6V nicht gerade sehr hoch. Absolut verrückt ist, dass ich (bei einem eher schlechten USB Kabel) hier dann auch 4.3 V am W5100 habe (und damit auch am STM32). Komisch ist, dass genau mit 4.3V das ganze besser läuft, als mit 4.6V.

Ich frage mich nun, ob der W5100 wirklich mit den auf der Platine vorgesehenen 5V überhaupt "zufrieden" ist. Der W5100 selbst, braucht ja nur 3V3, ein AMS1117 (5V->3V3) ist ja auf dem W5100 drauf.
Dennoch, bei allen SPannungsversorgungsvarianten bleibt eines bestehen:

1.) gleiche Platine (die alte MapleCUN ohne Aufdruck) läuft alles! mit der Alt-Firmware
2.) Stecke ich die Firmware vom 6.3.2017 drauf, läufts sehr unstabil.
3.) Ich habe sogar, um den STM32 auszuschliessen, den gleichen Maple Mini mal mit der Alt-Firmware, dann mit der neuen Firmware geflashed. Der Effekt ist reproduzierbar.

... und genau das ist mein Grund für die Ratlosigkeit.

Ich muss bei der Alt-Firmware bleiben (es läuft stabil) und die rfmodes=slowRF sowie HM tun das, was ich brauche. Wenn ich hier den Code de facto einfriere, stört es nicht besonders, weil ich bei slowRF nicht besonders viel Entwicklung zukünftig erwarte.


Viele Grüße!


Andreas


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 12 März 2017, 15:04:55
Ich hab mal deine Konfiguration nachgebaut, kann aber deinen Fehler nicht nachvollziehen. Bei mir läuft es.

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar  6 2017 18:53:31 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:E0:D5:7E
IP : 192.168.69.131
GW : 192.168.0.1
SN : 255.255.255.0
=======================================
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x14
-I- Detected CC2: PN 0x00  VER 0x14
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Detected ethernet
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]


Die Ports werden mit nmap erkannt:
pi@server ~ $ sudo nmap -sT 192.168.69.131 -p2323-2325

Starting Nmap 6.00 ( http://nmap.org ) at 2017-03-12 14:40 CET
Nmap scan report for WIZnet.fritz.box (192.168.69.131)
Host is up (0.00074s latency).
PORT     STATE SERVICE
2323/tcp open  3d-nfsd
2324/tcp open  unknown
2325/tcp open  ansysli
MAC Address: 00:80:41:E0:D5:7E (VEB Kombinat Robotron)

Nmap done: 1 IP address (1 host up) scanned in 0.58 seconds


Und über eine Verbindung mit Port 2323 lassen sich alle drei CC1101 Module ansprechen:
V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)
*V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 433MHz)
**V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)
? (1 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
*? (1 is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z *
**? (1 is unknown) Use one of b C A Z N E L Y V X f z
C30 = 00 /  0
*C30 = 00 /  0
**C30 = 00 /  0
C31 = 14 / 20
*C31 = 14 / 20
**C31 = 14 / 20


Das kommt mir bei dir komisch vor:
2017.03.12 12:33:29 3: mapleCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz
Da fehlt das * Kommando für den STACKABLE_CC. Das sollte aber drinn sein, wenn der zweite CC erkannt wird. Was liefert version hier zurück?

Zitat von: fhem-challenge am 12 März 2017, 15:00:55
Erklären würde es auch nciht, dass ich mit "nmap" keinen Port sehe, d.h. dass lediglich 2323 gebunden wird, aber die anderen CC1101 mit 2324,2325 ... nicht.
Die CC1101 sind alle über Port 2323 erreichbar. Die anderen Ports sind für die seriellen Schnittstellen des Maple.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: zentis666 am 12 März 2017, 17:54:58
Hallo,

ich hab mal ne Frage bezüglich Homematic-Protokoll:
wenn ich das richtig verstanden habe kann man die Homematic-Funkmodule für Raspberry anstatt der CC1101 Funkmodule einsetzen.

Könnte ich diese eigentlich genau wie ein "original" HomeMatic Funk-LAN-Gateway mit einer CCU2 verbinden oder funktioniert
das dann nur mit fhem / vccu? Anbindung des Moduls an fhem wäre ja - genau wie HomeMatic Funk-LAN-Gateway - per HMUARTLGW.

Gruß
Sven
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 12 März 2017, 18:34:58
Hi,
Zitat von: zentis666 am 12 März 2017, 17:54:58
ich hab mal ne Frage bezüglich Homematic-Protokoll:
wenn ich das richtig verstanden habe kann man die Homematic-Funkmodule für Raspberry anstatt der CC1101 Funkmodule einsetzen.
so ein Raspberry Modul wird nicht anstelle eines CC1101 genutzt sondern an eine der beiden UART Schnittstellen angeschlossen. Am Raspi geht das auf eine interne Serielle Schnittstelle, bei der Schaltung hier an interne Serielle vom Maple und das wird dann an die zweite/dritte USB-Schnittstelle bzw. an die Ports 2324 und 2325 gelegt.

Zitat von: zentis666 am 12 März 2017, 17:54:58
Könnte ich diese eigentlich genau wie ein "original" HomeMatic Funk-LAN-Gateway mit einer CCU2 verbinden oder funktioniert
das dann nur mit fhem / vccu? Anbindung des Moduls an fhem wäre ja - genau wie HomeMatic Funk-LAN-Gateway - per HMUARTLGW.
Hier kann ich Dir jetzt nicht mehr wirklich weiterhelfen, aber ich denke nicht das Du diese HW an eine CCU2 weiterreichen kannst. Aber eine CCU2 kenne ich nicht daher ist das hier nur meine Einschätzung.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 12 März 2017, 19:37:14
Zitat von: Telekatz am 12 März 2017, 15:04:55
Ich hab mal deine Konfiguration nachgebaut, kann aber deinen Fehler nicht nachvollziehen. Bei mir läuft es.

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar  6 2017 18:53:31 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:E0:D5:7E
IP : 192.168.69.131
GW : 192.168.0.1
SN : 255.255.255.0
=======================================
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x14
-I- Detected CC2: PN 0x00  VER 0x14
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Detected ethernet
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]


Die Ports werden mit nmap erkannt:
pi@server ~ $ sudo nmap -sT 192.168.69.131 -p2323-2325

Starting Nmap 6.00 ( http://nmap.org ) at 2017-03-12 14:40 CET
Nmap scan report for WIZnet.fritz.box (192.168.69.131)
Host is up (0.00074s latency).
PORT     STATE SERVICE
2323/tcp open  3d-nfsd
2324/tcp open  unknown
2325/tcp open  ansysli
MAC Address: 00:80:41:E0:D5:7E (VEB Kombinat Robotron)

Nmap done: 1 IP address (1 host up) scanned in 0.58 seconds


Und über eine Verbindung mit Port 2323 lassen sich alle drei CC1101 Module ansprechen:
V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)
*V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 433MHz)
**V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)
? (1 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
*? (1 is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z *
**? (1 is unknown) Use one of b C A Z N E L Y V X f z
C30 = 00 /  0
*C30 = 00 /  0
**C30 = 00 /  0
C31 = 14 / 20
*C31 = 14 / 20
**C31 = 14 / 20


Das kommt mir bei dir komisch vor:
2017.03.12 12:33:29 3: mapleCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz
Da fehlt das * Kommando für den STACKABLE_CC. Das sollte aber drinn sein, wenn der zweite CC erkannt wird. Was liefert version hier zurück?
Die CC1101 sind alle über Port 2323 erreichbar. Die anderen Ports sind für die seriellen Schnittstellen des Maple.


Danke,

also bei drei CC1101 sollte TCP:2323 reichen ? Okay, an den beiden serials hatte ich nichts dran.

version liefert: V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)

Ich habe jetzt auch: B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z * ... als valid commands bei der Initialisierung.

Frage: Kann es sein, dass es überdies Probleme gibt, wenn ich CC0 , aber NICHT! CC1, und dann wieder CC2,CC4 beschalte ? also, wenn der zweite (slowRF) nicht bestückt ist ?


Ich vermute eine leichte Hardwareabhängigkeit, die sich nur bei neueren releases der Firmware bemerkbar macht (ggf. verändertes Timing bei der Initialisierung des W5100 o.Ä.).


Viele Grüße!


Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 12 März 2017, 20:08:27
Anscheinend hat der Wiki Artikel einige verwirrt, weil sich die SW weiter entwickelt hat.
Ich habe somit den Part zum Flashen rausgenommen: https://wiki.fhem.de/wiki/MapleCUN#Firmware_.2F_Flashen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 12 März 2017, 20:10:27
Zitat von: fhem-challenge am 12 März 2017, 19:37:14
also bei drei CC1101 sollte TCP:2323 reichen ? Okay, an den beiden serials hatte ich nichts dran.
Der erste CC ist über TCP:2323 erreichbar, alle weiteren über STACKABLE_CC des jeweils vorherigen CC.

Zitat von: fhem-challenge am 12 März 2017, 19:37:14
Frage: Kann es sein, dass es überdies Probleme gibt, wenn ich CC0 , aber NICHT! CC1, und dann wieder CC2,CC4 beschalte ? also, wenn der zweite (slowRF) nicht bestückt ist ?
Ja, das gibt aktuell Probleme. Die weiteren CC können dann nicht mehr über * erreicht werden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 12 März 2017, 20:17:53
Zitat von: fhem-challenge am 12 März 2017, 19:37:14

Danke,

also bei drei CC1101 sollte TCP:2323 reichen ? Okay, an den beiden serials hatte ich nichts dran.

version liefert: V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) MapleCUNx4_87 (F-Band: 868MHz)

Ich habe jetzt auch: B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z * ... als valid commands bei der Initialisierung.

Frage: Kann es sein, dass es überdies Probleme gibt, wenn ich CC0 , aber NICHT! CC1, und dann wieder CC2,CC4 beschalte ? also, wenn der zweite (slowRF) nicht bestückt ist ?


Ich vermute eine leichte Hardwareabhängigkeit, die sich nur bei neueren releases der Firmware bemerkbar macht (ggf. verändertes Timing bei der Initialisierung des W5100 o.Ä.).


Viele Grüße!


Andreas



Ich konkretisiere meine Beobachtung einmal:

Wenn CC= beschaltet ist, CC1 nicht, CC3 und/oder CC4 wieder beschaltet sind, gibts Probleme.

Ich bekomme in diesem Fall lediglich CC0 (ccconf gibt etwas zurück). ALle weiteren CC(2-4) geben nichts zurück.

D.h. das beim parsen der CC's die Reihenfolge eingehalten bleiben muss. In meinem Fall einer TestPlatine ist es so, dass ich wg. des Auslöten eines Stamp Modules diesen (da die Leiterbahn da sich abgehoben haben) nicht mehr verwendet werden kann. Ich muss also hier CC=, CC2,CC3 berschalten, und genau das macht Probleme in FHEM.

Viele Grüße!


Andreas

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 12 März 2017, 20:29:21
Hi,
Zitat von: Telekatz am 12 März 2017, 20:10:27
Der erste CC ist über TCP:2323 erreichbar, alle weiteren über STACKABLE_CC des jeweils vorherigen CC.
Ja, das gibt aktuell Probleme. Die weiteren CC können dann nicht mehr über * erreicht werden.
also ich habe CC0 NICHT bestückt, dafür dann CC1/2/3 mit 868 Modulen. Das scheint aber zumindest bei meinem Kurztest mit Homematic zu funktionieren. Ich habe das mal mit der CUL Variante und auch mal mit der CUN Variante probiert und jedesmal das nicht existente CC0 als CUL eingebunden und dann drei mal "gestackt".

Macht die Konfiguration denn auch Probleme? Das wäre dumm da die Dinger ja als Briefmarke aufgelötet sind, und meine bestellten 434 Module dummerweise falsch mit 8 pin Header geliefert wurden.

Oder sind es bloss "Lücken" zwischen bestückten Modulen die Probleme machen?

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 12 März 2017, 21:05:26
Solange du für den nicht existierenden CC0 kein FastRF Protokoll einstellst, gibt es kein Problem. Es sind die Lücken dazwischen, die für Probleme sorgen. Ist das jeweils nächste Modul nicht erkannt worden, wird das * Kommando für den Zugriff darauf auch nicht angeboten. Auf alle weiteren kann man dann auch nicht mehr zugreifen.

Zitat von: fhem-challenge am 12 März 2017, 20:17:53
D.h. das beim parsen der CC's die Reihenfolge eingehalten bleiben muss. In meinem Fall einer TestPlatine ist es so, dass ich wg. des Auslöten eines Stamp Modules diesen (da die Leiterbahn da sich abgehoben haben) nicht mehr verwendet werden kann. Ich muss also hier CC=, CC2,CC3 berschalten, und genau das macht Probleme in FHEM.
Du könntest noch in der board.h die Reihenfolge der Module ändern, um CC1 zu Überspringen:
#define CCCOUNT             4
#define CCTRANSCEIVERS    {\
                          { {CC1100_0_OUT_BASE, CC1100_0_CS_BASE, CC1100_0_IN_BASE},\
                            {CC1100_0_OUT_PIN,  CC1100_0_CS_PIN,  CC1100_0_IN_PIN}  },\
                          { {CC1100_2_OUT_BASE, CC1100_2_CS_BASE, CC1100_2_IN_BASE},\
                            {CC1100_2_OUT_PIN,  CC1100_2_CS_PIN,  CC1100_2_IN_PIN}  },\
                          { {CC1100_3_OUT_BASE, CC1100_3_CS_BASE, CC1100_3_IN_BASE},\
                            {CC1100_3_OUT_PIN,  CC1100_3_CS_PIN,  CC1100_3_IN_PIN}  },\
                          { {CC1100_1_OUT_BASE, CC1100_1_CS_BASE, CC1100_1_IN_BASE},\
                            {CC1100_1_OUT_PIN,  CC1100_1_CS_PIN,  CC1100_1_IN_PIN}  },\                         
}


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 12 März 2017, 21:09:26
Hi,
Zitat von: Telekatz am 12 März 2017, 21:05:26
Solange du für den nicht existierenden CC0 kein FastRF Protokoll einstellst, gibt es kein Problem. Es sind die Lücken dazwischen, die für Probleme sorgen. Ist das jeweils nächste Modul nicht erkannt worden, wird das * Kommando für den Zugriff darauf auch nicht angeboten. Auf alle weiteren kann man dann auch nicht mehr zugreifen.
puh, dann habe ich ja unbewusst alles richtig gemacht indem ich für das nicht existierende CC0 slowRF ausgewählt habe.

Danke für die Klarstellung,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 12 März 2017, 21:28:56
Zitat von: Telekatz am 12 März 2017, 21:05:26
Solange du für den nicht existierenden CC0 kein FastRF Protokoll einstellst, gibt es kein Problem. Es sind die Lücken dazwischen, die für Probleme sorgen. Ist das jeweils nächste Modul nicht erkannt worden, wird das * Kommando für den Zugriff darauf auch nicht angeboten. Auf alle weiteren kann man dann auch nicht mehr zugreifen.
Du könntest noch in der board.h die Reihenfolge der Module ändern, um CC1 zu Überspringen:
#define CCCOUNT             4
#define CCTRANSCEIVERS    {\
                          { {CC1100_0_OUT_BASE, CC1100_0_CS_BASE, CC1100_0_IN_BASE},\
                            {CC1100_0_OUT_PIN,  CC1100_0_CS_PIN,  CC1100_0_IN_PIN}  },\
                          { {CC1100_2_OUT_BASE, CC1100_2_CS_BASE, CC1100_2_IN_BASE},\
                            {CC1100_2_OUT_PIN,  CC1100_2_CS_PIN,  CC1100_2_IN_PIN}  },\
                          { {CC1100_3_OUT_BASE, CC1100_3_CS_BASE, CC1100_3_IN_BASE},\
                            {CC1100_3_OUT_PIN,  CC1100_3_CS_PIN,  CC1100_3_IN_PIN}  },\
                          { {CC1100_1_OUT_BASE, CC1100_1_CS_BASE, CC1100_1_IN_BASE},\
                            {CC1100_1_OUT_PIN,  CC1100_1_CS_PIN,  CC1100_1_IN_PIN}  },\                         
}


Ahhh... okay. Dann verstehe ich das und meine Beobachtungen passen zur Realität.

Ist ja auch nur eine Ausnahme, da meine eine Platinen ein Defekt hat. Meine produktive Platinen hat das Problem ja nicht.


Viele Grüße!



Andreas

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stenny73 am 13 März 2017, 13:55:56
Zitat von: A.Harrenberg am 11 März 2017, 22:45:37
Hi,na so ein ZM3102 ist schon uralt und eigentlich auch nirgends wirklich zu bekommen.

Ich habe mir es Razberry2 gekauft den ich an einen UART anschliessen wollte. Habe die Teil zwar jetzt hier, bin aber noch nicht dazu gekommen das auszuprobieren. Wird diese Woche auch knapp und dann bin ich 2 Wochen in Urlaub. Aber ich gehe davon aus das das funktioniert, ebenso wie der HMUART den ich an die andere UART klemmen will ,-)

Gruß,
Andreas.

Hi

Klingt doch gut.....
Der zm3102 ist schon älter ist klar ein Nachfolger davon wäre schon sinnvoller.

Ich schaue im Moment nur was ich bei mir ändern könnte und das Teil sieht halt interessant aus.... die Alternative von busWare ist da schon extrem teurer.

stenny


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 13 März 2017, 21:13:54
Hi,
Zitat von: stenny73 am 13 März 2017, 13:55:56
Klingt doch gut.....
Der zm3102 ist schon älter ist klar ein Nachfolger davon wäre schon sinnvoller.
also einen Nachfolger wird es nicht geben, habe mit dem Entwickler von zwave.me deswegen schon mal diskutiert, er empfiehlt das Razberry-Modul zu nehmen. Leider ist das relativ teuer da man ja die Lizenz für ZWay gleich mitkauft und ohne Lizenz wird das Ding nicht vertrieben.

Ich habe in den sauren Apfel gebissen und mit das Modul gekauft. Habe in einem Raspi noch ein altes Razberry, das neue soll aber eine bessere Antenne haben, daher habe ich nicht das vorhandene Modul verplant.

Habe jetzt diese Woche nicht mehr so viel Zeit und bin dann 2 Wochen unterwegs, daher werde ich erst Anfang April dazu kommen das Modul mal an die UART dran zu hängen und damit rumzuspielen. Mir fällt nur gerade so auf das es in dem Gehäuse dann doch schon recht eng zugehen wird, ein Homematic-UART Modul (und das LAN-Modul) müssen ja auch noch da rein.

Zitat von: stenny73 am 13 März 2017, 13:55:56
Ich schaue im Moment nur was ich bei mir ändern könnte und das Teil sieht halt interessant aus.... die Alternative von busWare ist da schon extrem teurer.
Welche Alternative meinst Du denn?
Die Frage ist ja was Du da draufpacken willst. Meine "produktive" Platine wird wohl ein 433 + ein oder zwei 868 Module bekommen und dann eben Homematic und ZWave auf den UART Schnittstellen. Das ganze plane ich dann etwas günstiger in der Wohnung zu platzieren und per POE mit Strom zu versorgen.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 18 März 2017, 13:42:44
Guten Tag,

nachdem ich nun unendlich nach der Lösung der noch offenen Problematik gesucht habe, ist diese zumindest reproduzierbar und auf den "AutoDetect" der CC1101 Module zu fixieren.

Bei mir läuft NUR und ausschliesslich die Version:

V 1.23.07 a-culfw Build: private build (unknown) MapleCUNx4 (F-Band: 868MHz)

Alle Versionen mit der automatischen Erkennung der CC1101-Module funktionieren bei mir reproduzierbar nicht. D.h. es wird immer nur der erste CC1101 erkannt, alle folgenden nicht (es wird auch bei dem cmd kein * angeboten).

Wenn ich auf der gleichen! Platine den MapleMini mit V 1.23.07 drauf stecke, läuft alles.
Wenn ich auf eben diese Platine den mapleCUN mit culfw_1.24.01_build_205  stecke, wird nur der erste CC1101 erkant.

Ich vermute ein Problem im "Autodecet", etwas anderes kann es kaum noch sein. GGf. gibt es hier auch deutliche Fertigungsstreugungen in der Herstellung der Module. Sodass ggf. einige Module nicht (schnell genug) verfügbar sind, wenn das "AutoDecet" das Modul abfragt.

Frage: Kann man die AutoDetection der der culfw etwas verzögern, oder ggf. zweimal durchlaufen lassen ?

Ich habe als:

CC0 = 868 slowRF
CC1 = 433 slowRF
CC2 = 868 HM
CC3 = leer


Viele Grüße!



Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 März 2017, 14:06:49
Ich hab hier mal ein paar Verzögerungen eingebaut. Kannst du auch mal die Ausgaben an DBG aufnehmen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 18 März 2017, 15:13:26
Zitat von: Telekatz am 18 März 2017, 14:06:49
Ich hab hier mal ein paar Verzögerungen eingebaut. Kannst du auch mal die Ausgaben an DBG aufnehmen?


Prima, danke!


.... leider klappts noch nicht. Der erste CC1101 wird erkannt, alle weiteren nicht.

Ich habe noch eine zweite (identische) Platine, auf der ist die gleiche Anordnung der CC1101, mit dem einzigen Unterschied, dass an CC1 kein 433 Stamp gelötet ist, sondern ein CC1101 433 Modul gesteckt ist. Mit dem gesteckten Modul werden alle CC1101 erkannt. Deshalb vermute ich stark die Fertigungsstreuung zwischen den Modulen (oder Stamps).



Anbei die debug Ausgabe:


-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar 18 2017 13:48:23 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5100 NET CONF : Static =====
MAC : 00:80:41:08:D6:C0
IP : 192.168.100.243
GW : 192.168.100.254
SN : 255.255.255.0
=======================================
-I- init USB
-I- Detected CC0: PN 0x00  VER 0x14
-I- Not detected CC1: PN 0x00  VER 0x18
-I- Detected CC2: PN 0x00  VER 0x14
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Detected ethernet
-I- Autodetect result: 0x85
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]



Viele Grüße!


Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 18 März 2017, 15:25:16
Hi,
Wie ist das PanStamp drauf? Mit Adapter an gleichen 10 Pins oder direkt? Mal durchgemessen, nicht das doch Hardware schuld ist.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 März 2017, 15:54:51
Das liegt nicht an Fertigungsstreuungen, das liegt an den chinesischen Kopierkünsten. Das Problem hatte ich diese Woche auch schon. Ich nehme an, dein zweites Modul ist das hier:
https://de.aliexpress.com/item/433M-FSK-Transmitter-Receiver-kit-CC1101-SPI-RF-Wireless-Module-Transceiver/32737156299.html (https://de.aliexpress.com/item/433M-FSK-Transmitter-Receiver-kit-CC1101-SPI-RF-Wireless-Module-Transceiver/32737156299.html)

Das wird zwar als CC1101 Modul verkauft, frägt man aber das Versionsregister ab gibt es sich als CC113L aus. Der CC113L ist zwar eigentlich nur ein Receiver, trotzdem funktioniert bei mir auch senden mit diesem Modul. Auf dem Chip selber ist keine Aufdruck vorhanden.

Hier gibt es das gleiche Modul, diesmal aber korrekt beschrieben und mit lesbarer Beschriftung:
https://de.aliexpress.com/item/High-Frequency-Wireless-Receiving-Module-CC113L-Wireless-Module-Intelligent-Home-Furnishing-Receiver/32256596192.html (https://de.aliexpress.com/item/High-Frequency-Wireless-Receiving-Module-CC113L-Wireless-Module-Intelligent-Home-Furnishing-Receiver/32256596192.html)

Es gibt wohl noch eine andere Version dieses Moduls, eventuell wirklich mit CC1101:
https://de.aliexpress.com/item/2-8-3-6V-CC1100-CC1101-433M-Low-power-Wireless-Transceiver-Module-With-Antenna-Code-18/32719559399.html (https://de.aliexpress.com/item/2-8-3-6V-CC1100-CC1101-433M-Low-power-Wireless-Transceiver-Module-With-Antenna-Code-18/32719559399.html)

Mit der angefügten Version wird auch der CC113L erkannt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 18 März 2017, 16:40:22
Zitat von: Telekatz am 18 März 2017, 15:54:51
Das liegt nicht an Fertigungsstreuungen, das liegt an den chinesischen Kopierkünsten. Das Problem hatte ich diese Woche auch schon. Ich nehme an, dein zweites Modul ist das hier:
https://de.aliexpress.com/item/433M-FSK-Transmitter-Receiver-kit-CC1101-SPI-RF-Wireless-Module-Transceiver/32737156299.html (https://de.aliexpress.com/item/433M-FSK-Transmitter-Receiver-kit-CC1101-SPI-RF-Wireless-Module-Transceiver/32737156299.html)

Das wird zwar als CC1101 Modul verkauft, frägt man aber das Versionsregister ab gibt es sich als CC113L aus. Der CC113L ist zwar eigentlich nur ein Receiver, trotzdem funktioniert bei mir auch senden mit diesem Modul. Auf dem Chip selber ist keine Aufdruck vorhanden.

Hier gibt es das gleiche Modul, diesmal aber korrekt beschrieben und mit lesbarer Beschriftung:
https://de.aliexpress.com/item/High-Frequency-Wireless-Receiving-Module-CC113L-Wireless-Module-Intelligent-Home-Furnishing-Receiver/32256596192.html (https://de.aliexpress.com/item/High-Frequency-Wireless-Receiving-Module-CC113L-Wireless-Module-Intelligent-Home-Furnishing-Receiver/32256596192.html)

Es gibt wohl noch eine andere Version dieses Moduls, eventuell wirklich mit CC1101:
https://de.aliexpress.com/item/2-8-3-6V-CC1100-CC1101-433M-Low-power-Wireless-Transceiver-Module-With-Antenna-Code-18/32719559399.html (https://de.aliexpress.com/item/2-8-3-6V-CC1100-CC1101-433M-Low-power-Wireless-Transceiver-Module-With-Antenna-Code-18/32719559399.html)

Mit der angefügten Version wird auch der CC113L erkannt.


Ja, exakt --> Volltreffer.

Damit wird der CC113 erkannt und alles läuft.

Prima und vielen Dank!

Gruss

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 18 März 2017, 16:53:21
Da ich auch ein paar blaue Module (ohne lesbaren Aufdruck) bestellt habe, schon mal im voraus Danke !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Funsailor am 19 März 2017, 15:20:13
Hallo,
ich habe gestern meine MapleCul mit 3 CC-Einheiten in Betrieb genommen.

https://forum.fhem.de/index.php/topic,50990.msg607361.html#msg607361 und folgende Diskussion

Stand der Dinge:
Inzwischen habe ich den Maple Cul an FHEM laufen, die Kommunikation mit den Homematic und den MAX Geräte funktioniert einwandfrei.
Nur der alte CUN für die 433MHz Geräte hängt noch an meinem BananaPi und blockiert einen USB_Port.


Das Problem mit dem konfigurieren der Einheiten besteht weiterhin.

Die drei CULs laufen, state ist "Initialized".
Ich habe auf CC0 (mapleCUL1) und CC1 (mapleCUL2) je einen CC1101 mit  868MHz bestückt und auf dem CC2 (mapleCUL3) ein 434 MHz Modul.

mapleCUL1 ist im Homematic rfmode, mapleCUL2 im Max rfmode. Die Umstellung der Frequenz im mapleCUL2 auf 868 MHz war kein Problem. Bei diesen Devices kann ich aber z.B.: die bWidth nicht umstellen.

mapleCUL3 soll die 434MHz Devices bedienen. Allerdings kann ich das Device nicht auf 434MHz umstellen.

Woran kann das liegen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 19 März 2017, 16:49:13
Hi,
433.920 Mhz? Oder was genau ist der Fehler bei verbose 5 im Log?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 19 März 2017, 17:11:57
Zitat von: Funsailor am 19 März 2017, 15:20:13
mapleCUL1 ist im Homematic rfmode, mapleCUL2 im Max rfmode. Die Umstellung der Frequenz im mapleCUL2 auf 868 MHz war kein Problem. Bei diesen Devices kann ich aber z.B.: die bWidth nicht umstellen.

mapleCUL3 soll die 434MHz Devices bedienen. Allerdings kann ich das Device nicht auf 434MHz umstellen.

Woran kann das liegen?


Zitat von: Telekatz am 03 März 2017, 18:26:56
Folgende Einschränkungen gibt es für den Betrieb mit mehreren Transceivern:

  • SlowRF funktioniert nur an CC0 und CC1.
  • MBUS funktioniert an jedem Transceiver aber insgesamt nicht an mehr als einem Transceiver gleichzeitig.
  • KOPP_FC funktioniert nur an CC0.
Die restlichen Protokolle funktionieren an allen Transceivern und auch mehrfach gleichzeitig.

Die bWidth Einstellung ist nur für SlowRF, nicht für Homematix oder Max.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 19 März 2017, 17:36:42
Hi,
Naja, gibt es bei SlowRF nicht auch Geräte die neben der Frequenz liegen?

Aus dem CUL-Wiki:"Praktisch ist die Genauigkeit der Sendefrequenz der meisten SlowRF Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.
Frequenz und Bandbreite können daher im SlowRF Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden."
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 19 März 2017, 18:15:27
SlowRF geht nicht auf CC2, deshalb kann man da auch keine Frequenz einstellen!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 19 März 2017, 18:49:08
Hi Telekatz,
Sorry Du hast ja völlig recht und ich habe ein nicht übersehen ;-(
Alles Gut! danke für Deine tolle Arbeit hier!
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Funsailor am 20 März 2017, 11:52:29
Hallo,
muss ich dann die CC1 und CC2 tauschen?  :-[

Oder kann man da die Firmware anpassen?  8)
Die GDO0 und GDO2 Pins der CC0, CC1 und CC2 Module sind jeweils identisch mit Input-Output-Capture Einheiten (Capcom0,Capcom1 und Capcom2) verbunden. Das müsste dann doch gehen. Oder ist der Aufwand dafür zu groß?

Oder wird die Capcom2 Einheit anderweitig genutzt. Die Portpins des Capcom2 Blocks werden jedenfalls nicht doppelt genutzt.

LG
Michael

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 20 März 2017, 12:30:44
Die Reihenfolge der Module kann man in board.h ändern. Damit aber auch SlowRF funktioniert, muss noch der EXTI9_5_IRQHandler in stm32f1xx_it.c hinzugefügt werden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 20 März 2017, 13:02:45
Hi,
Kurzum: löt um! Sonst musst Du immer selbst patchen und kompilieren.
Gruß Arnd

Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Funsailor am 20 März 2017, 21:11:06
Hallo Telekatz,
das umstellen muss dann im Array CCTRANSCEIVERS gemacht werden.

Interrupt erweitern:
void EXTI9_5_IRQHandler(void)
{
  hal_GPIO_EXTI_IRQHandler();
}

Warum läßt du SlowRF nicht auf den unteren 3 CCs zu?

Dazu müsste man doch nur die Variable
#define NUM_SLOWRF          2
in 3 ändern.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 20 März 2017, 21:23:12
Man braucht dann immernoch einen dritten Timer.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Funsailor am 21 März 2017, 13:57:29
Hallo Telekatz,
es werden doch nur die Timer 1,2,3 genutzt?
  MX_TIM1_Init();
  MX_TIM2_Init();
  MX_TIM3_Init();

Aber der 103 hat noch den Timer4. Oder wird der irgendwo anders eingesetzt.
Eine Suche im Projekt nach TIM4 hat nichts ergeben (Außer die Eintragungen in den HAL Treibern).

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 21 März 2017, 17:52:36
Ich nehms mal in die Todo Liste auf.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 21 März 2017, 18:14:28
ZitatIch nehms mal in die Todo Liste auf.

Respekt für Deine Leidensfähigkeit !  8)
(Danke im Voraus)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Funsailor am 21 März 2017, 18:39:33
Hallo Telekatz,
wenn du willst kann ich mich an der Erweiterung beteiligen.

Das umstellen der CULs mit SlowRF  (tauschen CC1 und CC2 im Array CCTRANSCEIVERS) und die Erweiterung der Interrupts hat einwandfrei funktioniert. 8)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Funsailor am 22 März 2017, 18:47:56
Hmmm,
nun habe ich doch ein Problem.
Gestern habe ich die Frequenz der mapleCUL2 (Ich beginne bei der Definition mit mapleCUL1) auf 433.92MHz umgestellt und mit ccconf bestätigt bekommen.
Nach einem Update und sh restart wurde meine mapleCUL2 mit 868.3MHz initialisiert.

OK, dachte ich, vergessen zu speichern, once again.
Pustekuchen. Ich kann jetzt die Frequenz nicht mehr ändern.  ???

-> Wer das ohne die Vorangegangenen Infos liest: Ich habe die CC1 und CC2 in der Firmware gedreht. D.h.: bei meiner Maple CUL geht SlowRF an CC0 und CC2!

Hier der Eintrag im LOG beim Einstellen der Frequenz:


2017.03.22 18:53:15 4: CUL_Parse: mapleCUL1 A 0D E1 8410 1C5543 250560 0601210033 -48.5
2017.03.22 18:53:52 4: CUL_Parse: mapleCUL1 A 0C DC 8670 1EA6D9 000000 00C42B09 -69.5
2017.03.22 18:54:12 4: CUL_Parse: mapleCUL1 A 0B DC A258 1EA6D9 11252D 00F80A -69
2017.03.22 18:54:13 4: CUL_Parse: mapleCUL1 A 0E DC 8202 11252D 1EA6D9 0101C2003309 -69.5
2017.03.22 18:54:13 4: CUL_send:  mapleCUL1As 09 DD A112 250560 11252D
2017.03.22 18:55:36 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*W 0F 10   
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*W 10 b0   
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*W 11 71   
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*X 21     
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*A r   


Gesendet wird ja immer via mapleCUL1, die Adressierung der CUL erfolgt über die *

Das lesen der ccconf liefert:


mapleCUL2 ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB


get version gibt dann aber eine andere Info zurück:

mapleCUL2 version => V 1.24.01 a-culfw Build: private build (unknown) MapleCUNx4_07 (F-Band: 433MHz)


Noch mehr Fragezeichen.


Nun doch das ganz dickes Ausrufezeichen. :)

-> Der rfmode war nicht gespeichert.

Wahrscheinlich habe ich vor dem "sh restart" kein "save config" gemacht und damit war die Einstellung "rfmode SlowRF" wieder weg.

Dummerweise hatte der USB Stick für die LOG Dateien dann auch noch einen Crash, fhem konnte nach dem "sh restart" nicht starten.

Ich habe dann einen neuen Stick (der alte war auch ein wenig knapp bemessen) eingerichtet und die LOG Dateien der gestrigen Ablage von FHEM aufgespielt.

Und nach dem ich Fhem mit dem neuem Stick endlich wieder zum laufen gebracht hatte war der rfmode in Vergessenheit geraten....

Auf jeden Fall ist jetzt nach einem "sh restart" alles in Ordnung.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 22 März 2017, 19:15:04


2017.03.22 18:53:15 4: CUL_Parse: mapleCUL1 A 0D E1 8410 1C5543 250560 0601210033 -48.5
2017.03.22 18:53:52 4: CUL_Parse: mapleCUL1 A 0C DC 8670 1EA6D9 000000 00C42B09 -69.5
2017.03.22 18:54:12 4: CUL_Parse: mapleCUL1 A 0B DC A258 1EA6D9 11252D 00F80A -69
2017.03.22 18:54:13 4: CUL_Parse: mapleCUL1 A 0E DC 8202 11252D 1EA6D9 0101C2003309 -69.5
2017.03.22 18:54:13 4: CUL_send:  mapleCUL1As 09 DD A112 250560 11252D
2017.03.22 18:55:36 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*W 0F 10   
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*W 10 b0   
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*W 11 71   
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*X 21     
2017.03.22 18:55:36 4: CUL_send:  mapleCUL1*A r   

In der letzten Zeile wird Homematic aktiviert. Dann ist er wieder auf 868.3MHz.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Funsailor am 22 März 2017, 19:30:54
Hallo Telekatz,
das lag am falschem rfmode, ich habe meine Erkentnisse in meinen vorherigen thread eingetragen.
Das hat sich mit deiner Antwort überschnitten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 30 März 2017, 16:09:16
Hi,

bei mir laufen inzwischen die 4fach Transceiver (und auch LAN) sofort.

Zitat-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar 18 2017 15:46:32 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x18
-I- Detected CC2: PN 0x00  VER 0x14
-I- Detected CC3: PN 0x00  VER 0x14
-I- Not detected ethernet
-I- init USB
-I- init Complete

Bevor ich betriebsblind werde: Anfangs irritiert hat mich der rote Text. Man könnte meinen "LAN Modul erkannt". Spätestens wer kein LAN Modul verbaut hat erkennt, es geht nur um ein SW-Modul...

Einmal hatte ich das Problem dass das der MAPLE nicht mehr reagiert hat. Das war zu der Zeit als mein Firewall&Proxy-Server abgeraucht war. Logs habe ich dazu keine. Fakt ist nur das der Odroid (Ubuntu) einen Tag lang keinen LAN Zugriff hatte. Aber damit sollte es nicht zusammenhängen. Leider war ich sehr schnell dabei mal kurz das USB Kabel zu ziehen, anstatt die Kiste aufzuschrauben und das Debug-Käbelchen anzuschliessen oder checken ob die LED am MAPLE noch blinkt.

Das Modell "4-fach Produktiv" läuft bei mir gerade produktiv im Kemo Gehäuse (die ganz flache Version).
Die Version mit LAN Modul wird dieses vermutlich ablösen. (Den Odroid abschalten und FHEM auf dem dicken Server laufen lassen. IO dann über "das Funkmonster irgendwo am LAN"... )

Zukunft der Platinen:
-Ich habe vor noch einige zu fertigen (Im Moment auch noch Bestand vorhanden 1.3 und die abgespecktere 1.4)
-Grob bin ich jetzt mit dem Stand zufrieden, ein paar Kleinigkeiten werde ich noch verbessern.
-Als Standard sehe ich die V1.4 wo der MAPLE oben sitzt. Bei Nutzung des LAN Moduls kommt der MAPLE einfach einen Zentimeter tiefer (ohne irgendetwas zu drehen). Dadurch ist der USB Port genau auf der Ebene innerhalb der Platine.
Die dann unerreichbaren Buttons werden, solange der USB-Bootloader nicht zerstört wird, nie wieder benötigt. Für diesen Sonderfall, werde ich in der nächstem Version noch ein Loch für den entscheidenden Button einplanen.
(MAPLE unten mit Buttons zur Unterseite ist mir zu heiß. Da habe ich Sorge dass beim Verschrauben ggf. die Buttons durch das Gehäuse selbst gedrückt werden, das kann dann niemand mehr debuggen)


PS: Was sehr cool wäre: Der aktuelle Stand in nächster Zeit mal wieder fertig kompiliert. (Es gibt m.E. kein fertiges Binary für W5500 mit gleichzeitig der Erkennung "sonderbarer" Funkmodule...)


PPS: Von PeMue hatte ich mal den Vorschlag für ein hübscheres kleineres Gehäuse bekommen (https://forum.fhem.de/index.php/topic,68839.0.html). Das Problem: Ich habe mal etwas daran herumoptimiert und das Teil hat fast die selben Möglichkeiten wie "das Funkmonster" siehe Fotos. Die Platinen wären aber kaum billiger. Somit lege ich dieses Thema noch eine Weile auf Eis und warte auf weiteres Feedback. Denke ich würde diese Platine auch noch zwei mm schmäler machen, selbst wenn das Funktionen kosten würde... Dann können auf 10cm zwei PCBs gefertigt werden und bei 2*2mm Abstand wären die gut zu trennen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 30 März 2017, 18:59:07
Zitat von: Ranseyer am 30 März 2017, 16:09:16
PS: Was sehr cool wäre: Der aktuelle Stand in nächster Zeit mal wieder fertig kompiliert. (Es gibt m.E. kein fertiges Binary für W5500 mit gleichzeitig der Erkennung "sonderbarer" Funkmodule...)
Gibt es seit heute wieder.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: blueicechip am 31 März 2017, 10:28:16
Hallo,

Wie wäre es denn, wenn man bei der Version, bei der der Maple nach unten kommt, einfach zwei Microtaster auf der Platine vorsieht. Die beiden Tasten vom Maple sind doch rausgeführt, wenn ich das richtig gesehen habe.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 31 März 2017, 17:31:15
Zitat von: Telekatz am 30 März 2017, 18:59:07
Gibt es seit heute wieder.

Danke ! (Gleich geflasht und läuft bis jetzt)


ZitatWie wäre es denn, wenn man bei der Version, bei der der Maple nach unten kommt, einfach zwei Microtaster auf der Platine vorsieht.
Kritik an meiner Umsetzung ist immer sehr gerne willkommen. In dem Fall werde ich das jedoch nicht umsetzen weil:
Wenn der Maple-USB-Bootloader einmal getauscht ist sollte man daran nichts mehr machen.
Wenn doch, und dabei auch noch Probleme auftreten, sollte das ganze durch Anlöten eines einzigen Drahtes zu machen sein (der auf den passendes Potential gelegt wird und der MAPLE währenddessen angeschlossen wird).
Wenn dann noch ein Loch die Sache erleichtert per Button, sollte das mehr als genug sein...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 09 April 2017, 13:33:59
Hat jemand von euch einen Link für CC1101 Briefmarken Module mit 433MHz. Leider konnte ich dazu bisher nichts finden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 09 April 2017, 13:55:35
@gloob

hier gibt es CC1101 (868 & 434MHz) in verschieden Sorten.
http://www.tme.eu/de/details/rc-cc1101-spi-434/rf-kommunikationsmodule/radiocontrolli/#
http://www.tme.eu/de/details/rc-cc1101-smt-434/rf-kommunikationsmodule/radiocontrolli/rc-cc1101-spi-smt-434/#

pejonp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 09 April 2017, 14:00:16
Ich auch aber welche mit dem passenden Pin-Layout
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 April 2017, 14:32:11
Die von Pejonp sind für das Projekt nicht sinnvoll.

Wer minimal blättern kann findet hier Links von Telekatz: https://forum.fhem.de/index.php/topic,60458.msg607387.html#msg607387
Der war bei mir original und OK: https://de.aliexpress.com/item/2-8-3-6V-CC1100-CC1101-433M-Low-power-Wireless-Transceiver-Module-With-Antenna-Code-18/32719559399.html


Solche hier sollten es auch tun, und werden neuerdings seit letzter Firmwareanpassung auch korrekt initialisiert. (Allerdings bei mir nicht immer-immer: Selten muss ich den MAPLE auch nochmals reseten)
https://de.aliexpress.com/item/High-Frequency-Wireless-Receiving-Module-CC113L-Wireless-Module-Intelligent-Home-Furnishing-Receiver/32256596192.html

PS: Mir ist es das Wert für den Transceiver ein paar Euro mehr zu bezahlen. Aber dafür fest verlötet, also auch ohne jedes wackeln. Wer lieber Steckmodule nimmt hat mehr Auswahl zu besseren Preisen für 433MHz. Allerdings sieht es für 8866 MHz recht schlecht aus bei Steckmodulen. (Dafür habe ich Adapterplatinen um aus Stamps ein Steckmodul zu machen)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 14 April 2017, 15:19:14
Hallo Telekatz,

Ich versuche gerade mit der a-culfw und der 4xMapleCUL von Ranseyer Platine 3 ZWave-Empfänger gleichzeitig (mit verschiedenen Funk-Datenraten) in Betrieb zu nehmen. Hierbei haben Rudi und ich festgestellt das die Kommunikation mit dem Empfänger der nur mit 9600 Baud sendet mehr oder weniger i.O ist. Die beiden anderen Empfänger mit 40k und 100k Übertragungsrate empfangen im Schnitt aber nur 1/3 der Pakete. Vor allem scheinen alle "ACK" Nachrichten vom Maple nicht erkannt bzw. verschluckt zu werden.
Siehe auch diese Diskussion hier (https://forum.fhem.de/index.php/topic,68811.msg620191.html#msg620191), bzw. meine erste Anfrage an Björn hier (https://forum.fhem.de/index.php/topic,35064.msg620486.html#msg620486). Der Text hier entspricht mehr oder weniger der Anfrage an Björn.

Ich habe nun angefangen mir einige Debug-Zeilen mit TRACE_INFO_WP auf die serielle Debug-Schnittstelle zu schicken. Über ein kleines FHEM-Modul kann ich nun die serielle Schnitstelle öffnen und die Ausgabe per "Log3" mit in das fhem.log schreiben um es einfacher mit den Logzeilen des normalen ZWave-Dongels bzw. des ebenfalls mitlauschendem CUL vergleichen zu können.

Dabei fällt auf das hier das Zeilenende "\n" sehr oft fehlt und dadurch teilweise mehrere Zeilen als eine Zeile ausgegeben werden, da dann natürlich das splitten in FHEM nicht mehr funktioniert. Das sieht dann bespielsweise so aus:
2017.04.14 14:53:21.290 5: slog: 40k:  reading bytes from CC1100: done40k:  e015dfed0113050a4065 ,CS ok40k:  msg received with len:020

Das sind eigentlich drei Ausgaben, die jeweils mit "40k:" anfangen...

Ich habe mir das auch schon mal ohne den "Umfweg" über das Log, also direkt mit einem Terminal angesehen, dort ist es ebenfalls so, d.h. das newline geht nicht innerhalb von FHEM verloren.

Hast Du eine Idee was hier schief läuft? Die modifizierte rf_zwave.c mit den eingefügten TRACE_INFO_WP Zeilen habe ich mal angefügt.

Die Platine ist im übrigen voll bestückt, d.h. ein 433er Modul auf CC0, drei 868er Module auf den anderen Plätzen und ein W5100. Momentan habe ich sogar die serielle DBG auf den ersten UART Anschluss gelegt damit ich das alles über einen USB-Port auslesen kann...

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 14 April 2017, 15:46:56
Hast du es auch schon mit "\n\r" probiert?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 14 April 2017, 15:56:36
Hi,

nein habe ich nicht, aber im logging Modul wird nach /n getrennt und dann per Log3 ausgegeben, da würde mir ein /r ja auch den Output kaputt machen.

Die Frage ist aber warum das meist (aber eben nicht immer) verschluckt wird...

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 14 April 2017, 16:17:26
Passiert das auch, wenn du über einen anderen USB-Seriell Wandler direkt am DBG Anschluss loggst?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 14 April 2017, 16:26:23
Hallo Telekatz,

ja, momentan habe ich die DBG Leitung über Kreuz auf eine der UART Schnitsstellen von der Platine verbunden und nutze die gleiche USB-Schnittstelle wie für die CULs. Ich habe aber auch mit einem USB-Seriell Wandler direkt am DBG Anschluss das gleiche Problem. Einige Zeilen werden einfach nicht getrennt.

Ich werde aber jetzt noch mal mit /n/r testen und schauen wie es dann aussieht, ich erwarte dann aber unerwünschte Zeilenumbrüche...

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 14 April 2017, 16:38:45
Hi,

also mit /n/r werden die Zeilen teilweise "überschrieben", das bringt also auch nichts.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 14 April 2017, 16:58:15
Hi Telekatz,

ich habe jetzt mal alle \n durch \nblub\n ersetzt, d.h. eigentlich würde ich nach jeder normale Logzeile noch mal ein Zeile mit "blub" erwarten.

Wie Du siehst erscheint das "blub" manchmal richtig in einer einzelnen Zeile, andere Zeilen haben das "blub" aber vorne angesstellt, d.h. das letzte \n am Schluss wird irgendwie unterschlagen.

2017.04.14 16:47:46.640 5: slog: blub100k: msg received with len:043
2017.04.14 16:47:46.640 5: slog: blub
2017.04.14 16:47:46.640 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:46.898 5: slog: blub100k: fd95f8de67f9f12b966feedcdbc2afeff5cfbfffc7e7fd2f6bb7beadf3f4f7fcfefb9ef21f7fdff5fff9af, CS **not** ok!
2017.04.14 16:47:46.898 5: slog: blub100k: msg received with len:091
2017.04.14 16:47:46.898 5: slog: blub
2017.04.14 16:47:46.898 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:47.940 5: slog: blub100k: Discarding msg, bb437f6d9e134bcf ,len:207
2017.04.14 16:47:47.940 5: slog: blub
2017.04.14 16:47:48.413 5: slog: 100k: Discarding msg, d7fa3ec755b1efb5 ,len:181
2017.04.14 16:47:48.413 5: slog: blub
2017.04.14 16:47:48.578 5: slog: 100k: Discarding msg, 3f64df5e9efefbfc ,len:252
2017.04.14 16:47:48.578 5: slog: blub
2017.04.14 16:47:50.130 5: slog: 100k: msg received with len:155
2017.04.14 16:47:50.130 5: slog: blub
2017.04.14 16:47:50.130 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:50.253 5: slog: blub100k: Discarding msg, cd3beaff73f6e1e3 ,len:227
2017.04.14 16:47:50.253 5: slog: blub
2017.04.14 16:47:55.132 5: slog: 100k: Discarding msg, d97bfe62c2eb9beb ,len:235
2017.04.14 16:47:55.132 5: slog: blub
2017.04.14 16:47:56.864 5: slog: 100k: msg received with len:103
2017.04.14 16:47:56.864 5: slog: blub
2017.04.14 16:47:56.864 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:57.194 5: slog: blub100k: msg received with len:135
2017.04.14 16:47:57.195 5: slog: blub
2017.04.14 16:47:57.195 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:47:58.175 5: slog: blub100k: Discarding msg, fa1f7dcbfb61ffff ,len:255
2017.04.14 16:47:58.175 5: slog: blub
2017.04.14 16:48:01.357 5: slog: 100k: msg received with len:105
2017.04.14 16:48:01.357 5: slog: blub
2017.04.14 16:48:01.357 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:01.550 5: slog: blub100k: msg received with len:017
2017.04.14 16:48:01.550 5: slog: blub
2017.04.14 16:48:01.550 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:01.550 5: slog: blub100k: bfe7916a760831117f6f3319fa586fdbf9, CS **not** ok!
2017.04.14 16:48:03.104 5: slog: blub100k: msg received with len:123
2017.04.14 16:48:03.104 5: slog: blub
2017.04.14 16:48:03.104 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:04.252 5: slog: blub100k: msg received with len:039
2017.04.14 16:48:04.252 5: slog: blub
2017.04.14 16:48:04.252 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:04.253 5: slog: blub100k: 36f17fdbaff5d727c9f73168bdeeefee3ffff7da3d0797fff977b7fc83bb9ef97dbfdbff178c6f, CS **not** ok!
2017.04.14 16:48:04.734 5: slog: blub100k: msg received with len:015
2017.04.14 16:48:04.734 5: slog: blub
2017.04.14 16:48:04.734 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 16:48:04.734 5: slog: blub100k: 9bfed7dcfbdcc80f5feebdfd9affff, CS **not** ok!


Im übrigen bekomme ich einen Compilererror wenn ich nur ein \n ohne irgendetwas anderes ausgeben will:
TRACE_INFO_WP("\n");
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/sbrkr.c:58: undefined reference to `_sbrk'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-writer.o): In function `_write_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/writer.c:58: undefined reference to `_write'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-closer.o): In function `_close_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/closer.c:53: undefined reference to `_close'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-fstatr.o): In function `_fstat_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/fstatr.c:62: undefined reference to `_fstat'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-isattyr.o): In function `_isatty_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/isattyr.c:58: undefined reference to `_isatty'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-lseekr.o): In function `_lseek_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/lseekr.c:58: undefined reference to `_lseek'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-readr.o): In function `_read_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv7-m/newlib/libc/reent/../../../../../../newlib/libc/reent/readr.c:58: undefined reference to `_read'
collect2: error: ld returned 1 exit status

Keine Ahnung ob das in einem Zusammenhang steht, da dort ja im Prinzip aber nur ein printf aufgerufen wird wundert mich das schon.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 14 April 2017, 18:17:16
Da fängt GCC an printf zu optimieren und das verträgt sich dann nicht mit der größenoptimierten printf Implementierung in STM32/stdio.c.

Benenne in stdio.c die Funktion "printf" in "_printf" um und ersetze in trace.h alle "printf" durch "_printf", dann sollte es funktionieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 14 April 2017, 19:34:38
Hallo Telekatz!

Ja, das scheint es gewesen zu sein!

Das Logfile sieht jetzt schon fast gut aus...
Unter normalen Umständen wird jetzt das /n gesendet. Ich habe aber gerade noch ein paar Zeilen gefunden die recht lang sind und dann nicht vollständig ausgegeben werden und dann das /n auch wieder fehlt. Im Log weiter unten ist das z.B. die zweite Zeile und weiter unten noch mal.

100k: 7d9f6d26ee5e5a43eff65fb75e0feeffabf7ebdbf7bf56efebc7dbfeffffa2fe97fdbdfefff8fffffff771fc7f5b99fefd803fd7ea367c7edc7ff63fd1ffc3d33773ed, CS **
100k: de563aed57d47e3ff8dbd6bfff7fcc7e7053713ff3bf6fdebf6b149fb73d5eeff7ad1affffbddf2fe3ffefff19fffadf2bff5dffdf1fe47af5fe2e97f6dff7, CS **not** ok!


Was mich hier wundert ist das ich die lange Zahl ja einzeln ausgebe und danach noch mal "CS ok\n" oder "CS **not** ok!\n" anhänge, d.h. es dürfte eigentlich auch kein Bufferüberlauf stattfinden.
Ich habe noch ein paar weitere Nachrichten kontroliert, die sind alle genauso lang.

Allerdings scheint das mit dem "Weiterleiten" über den UART oder meinem Logging-Modul zu tun zu haben. Bei direktem logging an der DBG Schnittstelle gibt es teilweise VIEL längere Nachrichten die korrekt mit /n beendet werden.

Ist Dir im Code für die UART Schnittstellen vielleicht irgendwas bewusst was eine Längenbegrenzung verursachen würde? Im logging-Modul ist eigentlich nichts drin was das hervorrufen dürfte.

2017.04.14 18:59:37.903 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:41.022 5: slog: 100k: 7d9f6d26ee5e5a43eff65fb75e0feeffabf7ebdbf7bf56efebc7dbfeffffa2fe97fdbdfefff8fffffff771fc7f5b99fefd803fd7ea367c7edc7ff63fd1ffc3d33773ed, CS **n100k: Discarding msg, dac59affd8fd0caa ,len:170
2017.04.14 18:59:42.455 5: slog: 100k: Discarding msg, cf2d213c9b6e5bfb ,len:251
2017.04.14 18:59:43.417 5: slog: 100k: msg received with len:109
2017.04.14 18:59:43.417 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:43.563 5: slog: 100k: msg received with len:059
2017.04.14 18:59:43.563 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:43.563 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:43.565 5: slog: 100k: 647e57b78f98e63bf12edfbc3e7ffdff797dbf77f477f62bfff78faff33eff9bcfadb7f19efa1cffb7ddfdfff2e6dff7f7e7df52eb50d67bffaf9f, CS **not** ok!
2017.04.14 18:59:48.237 5: slog: 100k: msg received with len:063
2017.04.14 18:59:48.237 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:48.237 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:49.771 5: slog: 100k: de563aed57d47e3ff8dbd6bfff7fcc7e7053713ff3bf6fdebf6b149fb73d5eeff7ad1affffbddf2fe3ffefff19fffadf2bff5dffdf1fe47af5fe2e97f6dff7, CS **not** ok!100k: msg received with len:103
2017.04.14 18:59:49.771 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:51.535 5: slog: 100k: Discarding msg, 7dd7fd3fddbcdffd ,len:253


Auf jeden Fall schon mal vielen Dank für die Lösung mit _printf!
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 14 April 2017, 20:55:19
Wenn deine Debug Nachrichten während eines Durchlaufs des rf_zwave_task länger als 256 Bytes werden, läuft der serielle Empfangspuffer voll. Geleert wird der erst wieder in der main loop im cdc_uart_task.

Du könntest versuchen, die TTY_BUFSIZE in board.h zu erhöhen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 14 April 2017, 21:36:42
Hi,
Zitat von: Telekatz am 14 April 2017, 20:55:19
Wenn deine Debug Nachrichten während eines Durchlaufs des rf_zwave_task länger als 256 Bytes werden, läuft der serielle Empfangspuffer voll. Geleert wird der erst wieder in der main loop im cdc_uart_task.
das kann ich nicht ganz ausschliessen, aber glaube es eigentlich nicht. Die "Grenze" liegt ja anscheinend bei 148 bytes, danach geht es ja auch nicht mit irgendwelchem Müll weiter, sondern mit dem nächsten String. Und bis 256 ist da ja noch ein wenig "Platz"...

Zitat von: Telekatz am 14 April 2017, 20:55:19
Du könntest versuchen, die TTY_BUFSIZE in board.h zu erhöhen.
Werde ich mal probieren, ich schau auch mal in den cdc_uart_task, vielleicht kann ich da auch ein paar Debug-Zeilen einfügen um zu sehen wann da was passiert.
Aber das ist erst mal Nebenschauplatz.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 14 April 2017, 22:11:25
Zitat von: A.Harrenberg am 14 April 2017, 21:36:42
Hi,das kann ich nicht ganz ausschliessen, aber glaube es eigentlich nicht. Die "Grenze" liegt ja anscheinend bei 148 bytes, danach geht es ja auch nicht mit irgendwelchem Müll weiter, sondern mit dem nächsten String. Und bis 256 ist da ja noch ein wenig "Platz"...
Werde ich mal probieren, ich schau auch mal in den cdc_uart_task, vielleicht kann ich da auch ein paar Debug-Zeilen einfügen um zu sehen wann da was passiert.
Aber das ist erst mal Nebenschauplatz.

Gruß,
Andreas.
Da der Puffer während des rf_zwave_task nicht geleert wird, zählen alle Debugausgaben zu den 256 Bytes:
2017.04.14 18:59:48.237 5: slog: 100k: msg received with len:063
2017.04.14 18:59:48.237 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:48.237 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:49.771 5: slog: 100k: de563aed57d47e3ff8dbd6bfff7fcc7e7053713ff3bf6fdebf6b149fb73d5eeff7ad1affffbddf2fe3ffefff19fffadf2bff5dffdf1fe47af5fe2e97f6dff7, CS **not** ok!100k: msg received with len:103

Bis zum Ausrufezeichen sind das inklusive Zeilenumbrüche 256 Bytes.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 15 April 2017, 12:28:04
Hallo Telekatz,

ich würde gerne zu Debugzwecken das Signal GDO0 von den CC1100 Modulen nutzen. In ZWave ist der Pin vom cc1100 standardmäßig als 3-state definiert. Ich finde aber nicht wie/wo die IO-konfiguration für GDO0 (oder auch GDO2) beim Maple gemacht wird.

Für CS finde ich in cc1100.c:
#ifdef USE_HAL
  hal_CC_GDO_init(CC_INSTANCE,INIT_MODE_OUT_CS_IN);
#else
  EIMSK &= ~_BV(CC1100_INT);                 
  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN ); // CS as output
#endif

Das gleiche dann noch mal in rf_zwave.c:
#ifdef USE_HAL
hal_CC_GDO_init(CC_INSTANCE,INIT_MODE_OUT_CS_IN);
#else
  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
#endif

Für GDO0 oder GDO2 finde ich keine explizite Initialisierung.

Auf der Platine von Ranseyer wäre das für
CC0 -> CC_OUT_0 = Pin 10 = PA1
CC1 -> CC_OUT_1 = Pin 17 = PB5
CC2 -> CC_OUT_2 = Pin 13 = PC14
CC3 -> CC_OUT_3 -> existiert nicht

Kann ich mich darauf verlassen das die drei Pins auf Input (oder im 3-state mode) sind? Ich möchte nicht unbedingt den cc1100 als Ausgang schalten wenn der Maple den Pin auf Output gesetzt hat.

Wäre nett wenn Du mir hier noch weiterhelfen könntest wo (und wie) die HW-Initianlisierung stattfindet.

Danke,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 15 April 2017, 12:58:17
Die Initialisierung der drei GDO Pins des Maples erfolgt in hal_CC_GDO_init. Mit dem Parameter INIT_MODE_OUT_CS_IN wird der Pin für GDO0 am Maple als Ausgang und der Pin für GDO2 als Eingang konfiguriert. Wenn du beide Pins als Eingang definieren möchtest, verwende den Parameter INIT_MODE_IN_CS_IN.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 15 April 2017, 15:02:15
Hi,
Zitat von: Telekatz am 15 April 2017, 12:58:17
Die Initialisierung der drei GDO Pins des Maples erfolgt in hal_CC_GDO_init. Mit dem Parameter INIT_MODE_OUT_CS_IN wird der Pin für GDO0 am Maple als Ausgang und der Pin für GDO2 als Eingang konfiguriert. Wenn du beide Pins als Eingang definieren möchtest, verwende den Parameter INIT_MODE_IN_CS_IN.
danke für die RM. Da bin ich aber froh das ich nicht einfach davon ausgegangen bin das der Pin Input/3-state ist...

Ich bin gar nicht auf die Idee gekommen das in dem Codewort alle drei Signale drin stecken, wobei das jetzt mit dem Namen sogar logisch ist.
Vielleicht wäre es sogar eine gute Idee in rf_zwave.c das "INIT_MODE_IN_CS_IN" in den Code zu übernehmen. Der Pin wird in zwave nicht genutzt und kann deshalb auch genausogut Input sein, was im Zweifelsfall besser ist als Output.

Noch eine weitere Frage: Gibt es in der Firmware ein globales Zeitsignal bzw. ein forlaufender Counter den man jederzeit abfragen kann? Ich würde gerne an ein paar Stellen im Code abfragen um eine Zeitabschätzung vornehmen zu können. Momentan logge ich mit einem LogicAnalyser die Pins zu den cc1100 und sehe da teilweise recht lange "Pausen" von etlichen millisekunden die ich mir nicht so wirklich erklären kann.

Danke,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 15 April 2017, 16:02:12
Über HAL_GetTick() gibt es eine Counter mit 1 ms Auflösung. Wenn du eine größerer Auflösung benötigst, müsstest du dir etwas mit dem Cycle Count Register DWT->CYCCNT erstellen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 16 April 2017, 18:33:33
Hi Telekatz,
Zitat von: A.Harrenberg am 15 April 2017, 15:02:15
Vielleicht wäre es sogar eine gute Idee in rf_zwave.c das "INIT_MODE_IN_CS_IN" in den Code zu übernehmen. Der Pin wird in zwave nicht genutzt und kann deshalb auch genausogut Input sein, was im Zweifelsfall besser ist als Output.
ich bin jetzt definitiv der Meinung das "INIT_MODE_IN_CS_IN" der Default sein sollte. In rf_zwave_init() wird ein reset befehl an den CC1100 geschickt und danach werden die Kontrollregister beschrieben.
Der Default nach Reset für die Konfiguration des GDO0 ist aber 0x3F, was einem Output von CLK_XOSC/192 enstpricht. D.h. solange bis das Register neu mit 0x2e (3-State) beschrieben wurde arbeiten die Ausgänge von Maple und CC1100 gegeneinander.

Ich kann nämlich jetzt nach dem Reset schön das Taktsignal sehen bis dann das Register neu beschrieben wird.

Gruß,
Andreas.
Titel: MapleCUL USB-Stick mit zwei CC1101 Transceivern
Beitrag von: locutus am 17 April 2017, 21:50:12
Hallo zusammen,

ich möchte euch meine Version des MapleCUL in Form eines USB-Sticks vorstellen.
Der USB-Stick besteht in wesentlichen aus einem STM32-Mikrocontroller und einem CC1101 Funkmodul. Weitere Merkmale:
- optionaler zweiter CC1101 Transceiver
- BOOT und RESET Taster
- 4 pol. Debug- und Programmierschnittstelle
- UART (TX1/RX1) Erweiterung
- LED Indicator
- optionale SMA-Buchse(n)
- a-culfw (https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/MapleCUN)
Abmessungen ohne USB-Stecker (LxB): 50 x 18 mm

Zum Programmieren der a-culfw Firmware ist ein zusätzlicher USB zu TTL Wandler mit 3.3V Logik zwingend erforderlich.
Firmware bauen:
make clean
make MapleCULx4

Firmware (Bootloader freie Version) flashen:
- GND/3V3/RX/TX am MapleCUL mit einem USB zu TTL Adapter verbinden.
- USB zu TTL Adapter mit dem PC verbinden.
- Taste BOOT am MapleCUL drücken und gerdückt halten.
- Taste RST am MapleCUL drücken.
- Tasten loslassen.
- STM32 Flash loader demonstrator starten.
- COM Port des USB zu TTL Wandlers auswählen, Baud Rate 115200, Parity Even, Echo Disabled, Timeout 1.
- Auf Next drücken.
- Es sollte die Meldung erscheinen: Target is readable. Please click "Next" to proceed.
- Auf Next drücken.
- Auf Next drücken.
- Download to device auswählen.
- Datei MapleCULx4.bin öffnen.
- Erase necessary pages auswählen.
- Auf Next drücken.
- Warten bis Flashvorgang abgeschlossen ist.
- USB zu TTL Adapter vom MapleCUL entfernen.

Der erste Transceiver wird als CUL angelegt.
define mapleCUL1 CUL /dev/ttyACM0@38400 0123
Der zweite Transceiver wird als STACABLE_CC angelegt.
define mapleCUL2 STACKABLE_CC mapleCUL1

Im Anhang Gerberdaten, Warenkorb (Stückliste) und Schaltplan für Interessierte, die auch gern selbst mal wieder zum Lötkolben greifen wollen.
Bezugsquelle für ...
unbestückte Leiterplatte(n): ITEAD Studio (https://www.itead.cc/open-pcb/pcb-prototyping/2layer-green-pcb-5cm-x-5cm-max.html)
Bauteile: Reichelt Elektronik
CC1101 Funkmodul: eBay
2 Pin Push Button 4 x 3 x 1.8 mm: eBay

Die Verwendung der Daten für kommerzielle Zwecke, Herstellung oder gewerblichen Vertrieb ist untersagt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 20 April 2017, 18:40:21
Hallo Locutus,

hättest Du noch eine Leerplatine für mich übrig?

Grüße,
Jürgen

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 21 April 2017, 19:32:32
Leider nein! Nur Fertiggeräte sind in begrenzter Stückzahl verfügbar.
https://forum.fhem.de/index.php/topic,65998.0.html
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 26 April 2017, 09:58:46
Guten Morgen,
nachdem mein erster Maple CUL jetzt produktiv läuft ich aber parallel auch mal über einen originalen Busware Stick gefallen bin, habe ich mir die Wikis im Detail durchgelesen. Dabei ist mir aufgefallen, dass das Attribut model CUN beim Maple noch gar nicht diskutiert wurde und nicht im Wiki steht. Konkret:


1.) Wozu wird das attr model überhaupt verwendet?
2.) Brauchet der Maple CUL (Platine ohne Ethernet) ein CUL oder ein CUN?
3.) Brauchet der Maple CUN (Platine mit Ethernet WS5100 oder WS5500) ein CUL oder ein CUN oder müssten wir sogar zwei neue definieren lassen?

Danke für Eure Klärung!

Gruß Arnd
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kleo am 30 April 2017, 23:09:07
Hallo , ich bin relativer FHEM-Neuling und habe mich am Zusamenbau eines MapleCUL versucht.
Ich habe einen 868MHz CC1101 als ersten und einen 433MHz CC1101 als zweiten Transceiver verbaut.

Ich habe alles nach Wiki und Forumsbeitrag eingerichtet (insbesondere den zweiten Transceiver als gestackt angelegt).
Das scheint auch soweit zu funktionieren. Der erste Transceiver ist im MAX Modus und empfängt meine Thermostate und Türkontakte.
Der zweite (im SlowRF Modus) scheint meine ELRO Funksteckdosen zu schalten (laut Logfile jedenfalls).

Ich bin trotzdem verunsichert, ob jetzt alles richtig eingerichtet ist. Vielleicht kann einer der Experten mal einen kurzen Blick auf
die FHEM-Definitionen für meine beiden Transceiver werfen?

#EDIT (Screenshots durch Code-Listings ersetzt)
Erster CUL/Transceiver (868MHz)
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@38400 4444
   DeviceName /dev/ttyACM0@38400
   FD         5
   FHTID      4444
   NAME       mapleCUL868
   NR         20
   PARTIAL
   RAWMSG     Z0B330002022EA4025524000046
   RSSI       -39
   STACKED    mapleCUL433
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 868MHz)
   initString X21
Zr
   mapleCUL868_MSGCNT 4
   mapleCUL868_TIME 2017-05-01 10:30:27
   Matchlist:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-04-30 23:11:51   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-05-01 10:26:55   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2017-04-30 22:49:49   credit10ms      207
     2017-04-30 21:17:38   raw             is00F00F0FFFFF
     2017-05-01 10:30:27   state           Initialized
Attributes:
   rfmode     MAX



Zweiter, gestackter Transceiver (433MHz)
Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        mapleCUL868
   IODev      mapleCUL868
   NAME       mapleCUL433
   NOTIFYDEV  mapleCUL868
   NR         30
   NTFY_ORDER 50-mapleCUL433
   PARTIAL
   RAWMSG     r5A47E500133201264401C43C
   RSSI       -44
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 433MHz)
   initString X21
   mapleCUL433_MSGCNT 1
   mapleCUL433_TIME 2017-05-01 10:26:58
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-04-30 23:11:36   ccconf          freq:433.970MHz bWidth:406KHz rAmpl:42dB sens:8dB
     2017-05-01 10:26:55   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2017-05-01 10:29:21   raw             6
     2017-05-01 10:26:58   state           Initialized
     2017-04-30 22:08:30   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 433MHz)
Attributes:
   rfmode     SlowRF


CUL_MAX
Internals:
   CM_MSGCNT  1
   CM_TIME    2017-05-01 10:30:27
   DEF        123456
   IODev      mapleCUL868
   LASTInputDev mapleCUL868
   MSGCNT     3
   NAME       CM
   NR         23
   STATE      Defined
   TYPE       CUL_MAX
   addr       123456
   cnt        0
   mapleCUL868_MSGCNT 2
   mapleCUL868_RAWMSG Z0B330002022EA40255240000
   mapleCUL868_RSSI -39
   mapleCUL868_TIME 2017-05-01 10:30:27
   pairmode   0
   retryCount 0
   Readings:
     2017-04-30 22:49:52   packetsLost     5
   sendQueue:
Attributes:
   IODev      mapleCUL868


Vielen Dank, Kleo
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: KernSani am 01 Mai 2017, 00:01:35
Zitat von: kleo am 30 April 2017, 23:09:07
Hallo , ich bin relativer FHEM-Neuling und habe mich am Zusamenbau eines MapleCUL versucht.
Ich habe einen 868MHz CC1101 als ersten und einen 433MHz CC1101 als zweiten Transceiver verbaut.

Ich habe alles nach Wiki und Forumsbeitrag eingerichtet (insbesondere den zweiten Transceiver als gestackt angelegt).
Das scheint auch soweit zu funktionieren. Der erste Transceiver ist im MAX Modus und empfängt meine Thermostate und Türkontakte.
Der zweite (im SlowRF Modus) scheint meine ELRO Funksteckdosen zu schalten (laut Logfile jedenfalls).

Ich bin trotzdem verunsichert, ob jetzt alles richtig eingerichtet ist. Vielleicht kann einer der Experten mal einen kurzen Blick auf
die FHEM-Definitionen für meine beiden Transceiver werfen?

Vielen Dank, Kleo
Weiterhelfen kann ich dir nicht, aber als Tipp: Screenshots mag niemand gerne. Gib lieber list <device> in die Kommandozeile ein und poste den Output.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kleo am 01 Mai 2017, 10:36:15
Zitat von: KernSani am 01 Mai 2017, 00:01:35
Weiterhelfen kann ich dir nicht, aber als Tipp: Screenshots mag niemand gerne. Gib lieber list <device> in die Kommandozeile ein und poste den Output.

Danke für den Hinweis. Das ist nachvollziehbar und ich habe es gleich mal umgesetzt.
Grüße, Kleo
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 01 Mai 2017, 13:08:58
Hi,
Zitat von: juergs am 01 Mai 2017, 10:53:00
Hallo KernSani,

bist Du sicher?

Ok, Spaß beiseite lösche es wieder raus  :) :) :) :)
das ist der Unterschied zwischen den Zitat-Tags und den Code-Tags... Soetwas gehört in Code-Tags und dann ist auch nicht mehr so schlimm.

Aber ich würde auch vorschlagen das wieder zu entfernen ;-)

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Capricornus73 am 07 Mai 2017, 13:54:31
Guten Morgen zusammen,

ich habe mir den MapleCUN nun selber gebaut mit 2 CC1101 Funkmodulen (433 MHz und 868 MHz) und einem HMUART mit dem HM-MOD-RPI-PCB. Die beiden Funkmodule funktionierten sofort ohne Probleme.
Mir war wichtig, dass alle Module über USB ansprechbar sind auch die UART Schnittstellen des Maple mini und falls jemand von euch auch Probleme damit hat und ich gerne helfen möchte, schreibe ich hier meine Lösung nieder.

Erst konnte ich den UART über USB nicht ansprechen und nach langem Lesen in diversen Foren habe ich herausgefunden, dass sich dies UART Schnittstellen folgender maßen ansprechen lassen:

-Für UART 0 in FHEM: define myHmUART HMUARTLGW /dev/ttyACM1@Baudrate des Devices

-Für UART 1 in FHEM: define myHmUART HMUARTLGW /dev/ttyACM2@115200 das ist mein HMUART.  :D

Und zweitens konnte ich über FHEM nicht mit dem HM-MOD-RPI-PCB komunizieren. Das Device war not connected. >:(

Bei meinem Maple mini sind die TX und RX Anschlüsse vertauscht, das habe ich beim Bootloader flashen festgestellt und nachdem ich beim HM-MOD-RPI-PCB die Anschlüsse für TX und RX getauscht hatte funktionierte das HM-MOD-RPI-PCB auch endlich fehlerfrei!

Damit das ganze dann in FHEM funktioniert, muss für das myHmUART noch eine zusätzliche HmId vergeben werden: attr myHmUART hmId 424242
Der HM-MOD-RPI-PCB hat zwar schon eine eigene HmId aber damit dieser auch Empfangen kann benötigt dieser noch eine zweite HmId.

Bemerkbar macht sich das Fehler der zusätzlichen HmId folgender maßen: Das Pairen von HM Geräten klappt, aber wenn man z.B. die Config eine HM Gerätes auslesen möchte, dann schlägt dieses fehl und es kommt zu einem Time Out!

Falls jemand Probleme mit dem Flashen des Bootloader hat, da habe ich folgendes gemacht: Ich habe einen Jumper an dem boot1 Anschluss des Maple minis angeschlossen und zwar so dass ich den boot1 Anschluss für das Flashen auf GND (low) setzen kann und für den Normalbetrieb auf +3,3V (high). Als Pullup/Pulldown Widerstand habe ich jeweils ein 10 KOhm Widerstand benutzt.

Als Anhang habe ich noch meinen Verdrahtungsplan für eine Lochrasterplatine für euch. Blaue Verbindungen sind Brücken! Und die Bezeichnung für RX und TX sind so bezeichnet, wie ich den USB zu TTL Konverter anschließen muss. Also TX an TX und RX an RX!

Ich hoffe ich konnte dem Einen oder Anderen weiter helfen und wünsche euch allen noch einen schönen Sonntag  :)

Viele Grüße Jörg

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bartman121 am 10 Mai 2017, 13:52:53
Hallo,

ich stell mich irgendwie zu dämlich an, die Firmware selbst zu kompilieren, daher frage ich mal ganz frech ob es möglich ist, die a-culfw mit aktiviertem:
#define LACROSSE_HMS_EMU bereitzustellen?

Damit könnte man dann auch bequem seine LaCrosse-Sensoren empfangen und könnnte den JeeLink "entsorgen" --> LaCrosse für CUL (https://forum.fhem.de/index.php/topic,36565.msg289082.html#msg289082)

Grüße
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bartman121 am 11 Mai 2017, 07:44:31
also  ich versuche mich derzeit am kompilieren, jedoch scheitert es immer hier:

/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: ../../clib/cc1100.o: Relocations in generic ELF (EM: 83)
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: ../../clib/cc1100.o: Relocations in generic ELF (EM: 83)
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: ../../clib/cc1100.o: Relocations in generic ELF (EM: 83)
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: ../../clib/cc1100.o: Relocations in generic ELF (EM: 83)
../../clib/cc1100.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
makefile:236: die Regel für Ziel ,,MapleCUNx4_W5100_BL.elf" scheiterte
make[1]: *** [MapleCUNx4_W5100_BL.elf] Fehler 1
make[1]: Verzeichnis ,,/home/andreas/a-culfw/culfw/Devices/MapleCUN" wird verlassen
makefile:200: die Regel für Ziel ,,all" scheiterte
make: *** [all] Fehler 2


Kann Jemand damit etwas anfangen und mich in die richtige Richtung schubbsen?

Danke schon im voraus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 11 Mai 2017, 09:04:11
@bartman121

Mach mal ein: make clean
Und dann ein: make

Pejonp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bartman121 am 11 Mai 2017, 10:30:05
Hallo,

also erstmal vielen Dank, das kompilieren ging dann auch, jedoch funktioniert es - wie zu erwarten - doch nicht zu einfach.

Ich habe in der board.h folgendes ergänzt:
#define LACROSSE_HMS_EMU

im makefile auch die entsprechende lib eingebunden:
SRCS += ../../clib/lacrosse.c

Danach kann man mittels
set MapleCulXX raw Nr1
oder
set MapleCulXX raw Nr2

den LaCrosse Empfang aktivieren. Es wird auch empfangen und die entsprechenden HMS-Devices werden werden angelegt und befüttert.

ABER irgendwo ist der WURM drin, danach dreht FHEM ein wenig durch :(

2017.05.11 10:23:27 2: autocreate: define STACKABLE_CC_25 STACKABLE_CC STACKABLE                                                _CC_24
2017.05.11 10:23:46 2: autocreate: define STACKABLE_CC_26 STACKABLE_CC STACKABLE                                                _CC_25
2017.05.11 10:24:05 2: autocreate: define STACKABLE_CC_27 STACKABLE_CC STACKABLE                                                _CC_26
2017.05.11 10:24:24 2: autocreate: define STACKABLE_CC_28 STACKABLE_CC STACKABLE                                                _CC_27
2017.05.11 10:24:43 2: autocreate: define STACKABLE_CC_29 STACKABLE_CC STACKABLE                                                _CC_28
2017.05.11 10:25:02 2: autocreate: define STACKABLE_CC_30 STACKABLE_CC STACKABLE                                                _CC_29
2017.05.11 10:25:21 2: autocreate: define STACKABLE_CC_31 STACKABLE_CC STACKABLE                                                _CC_30
2017.05.11 10:25:41 2: autocreate: define STACKABLE_CC_32 STACKABLE_CC STACKABLE                                                _CC_31
2017.05.11 10:26:00 2: autocreate: define STACKABLE_CC_33 STACKABLE_CC STACKABLE_CC_32


hier mal das list eines der LaCrosse-Sensoren:

Internals:
   CFGFN
   CHANGED
   CODE       4305
   DEF        4305
   IODev      nanoCUL_LC
   LASTInputDev STACKABLE_CC_19
   MSGCNT     15
   NAME       HMS100T_4305
   NR         274
   STACKABLE_CC_13_MSGCNT 6
   STACKABLE_CC_13_RAWMSG 810e04xx0511a0014305000001840100
   STACKABLE_CC_13_RSSI -74.5
   STACKABLE_CC_13_TIME 2017-05-11 10:18:04
   STACKABLE_CC_14_MSGCNT 3
   STACKABLE_CC_14_RAWMSG 810e04xx0511a0014305000001840100
   STACKABLE_CC_14_RSSI -74.5
   STACKABLE_CC_14_TIME 2017-05-11 10:18:28
   STACKABLE_CC_15_MSGCNT 3
   STACKABLE_CC_15_RAWMSG 810e04xx0511a0014305000001840100
   STACKABLE_CC_15_RSSI -74.5
   STACKABLE_CC_15_TIME 2017-05-11 10:19:09
   STACKABLE_CC_18_MSGCNT 2
   STACKABLE_CC_18_RAWMSG 810e04xx0511a0014305000001840100
   STACKABLE_CC_18_RSSI -74.5
   STACKABLE_CC_18_TIME 2017-05-11 10:18:44
   STACKABLE_CC_19_MSGCNT 1
   STACKABLE_CC_19_RAWMSG 810e04xx0511a0014305000001840100
   STACKABLE_CC_19_RSSI -74.5
   STACKABLE_CC_19_TIME 2017-05-11 10:19:17
   STATE      T: 18.4  Bat: ok
   TYPE       HMS
   Helper:
     Dblog:
       Data:
         Logdb:
           TIME       1494490636.15632
           VALUE      T: 18.4  Bat: ok
       Temperature:
         Logdb:
           TIME       1494490636.15632
           VALUE      18.4
   Readings:
     2017-05-11 10:19:17   battery         ok
     2017-05-11 10:19:17   state           T: 18.4  Bat: ok
     2017-05-11 10:19:17   temperature     18.4
     2017-05-11 10:19:17   type            HMS100T


Hier wären dann jetzt vermutlich doch die Profis gefragt ... Es wäre super, wenn sich das mal Jemand ansehen würde, der LaCrosse-Empfang ist vermutlich nicht nur für mich recht interessant.

EDIT: das alte IOdev nanoCUL_LC war nur zum Testen, es ist beim o.g. Code nicht angeschlossen gewesen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 11 Mai 2017, 11:41:59
@bartman121

Wie groß ist die kompilierte Datei? Bei mir hatte ich das Problem das bei 65k , durch Einbau von lacrosse, die Datei nicht mehr richtig lief (Blue pill). Bin jetzt aber auch nicht drangeblieben, um den Fehler zugingen.

Pejonp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bartman121 am 11 Mai 2017, 12:26:26
Hallo Pejomp,

du hast es also auch schonmal probiert ...


-rwxr-xr-x  1 root    root    50672 Mai 11 09:10 MapleCUNx4_W5100_BL.bin
-rwxr-xr-x  1 root    root    59436 Mai 11 09:10 MapleCUNx4_W5500_BL.bin

also 51kB und 59,5kB .... ich befürchte eher, dass das Problem an einer anderen Stelle steckt, ich warte einfach mal ab ob es Jemand hinbekommt.

Empfangen von LaCrosse funktioniert ja schon, lediglich, dass weiterverarbeiten ist noch nicht an. Irgendwie muss es doch eine Lösung geben.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 11 Mai 2017, 13:12:51
@bartman121

Ich hatte auch noch Debug aktiviert, so das ich über die uart mitlesen konnte. Im fhem sollten eigentlich
HMS Geräte angelegt werden.

Pejonp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bartman121 am 12 Mai 2017, 14:16:23
Hallo Pejonp,

also irgendwie staune ich heute nicht schlecht. Ich habe einfach mal meine selbst kompilierte (von gestern) W5500-Bin aufgespielt. Jetzt funktioniert der Lacrosse-Empfang plötzlich. Ich werde das mal beobachten.

Grüße

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: chris1284 am 15 Mai 2017, 19:27:53
ich versuche gerade die a-culfw zu compilieren um lacrosse zu aktivieren, scheitere aber
Zitatmake[1]: arm-none-eabi-gcc: Kommando nicht gefunden
makefile:231: recipe for target 'main.o' failed
make[1]: *** [main.o] Error 127
make[1]: Leaving directory '/opt/a-culfw-master/culfw/Devices/MapleCUN'
makefile:201: recipe for target 'all' failed
make: *** [all] Error 2

gibt es ein paket für arm-none-eabi-gcc ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 15 Mai 2017, 19:32:36
Hi,
Zitat von: chris1284 am 15 Mai 2017, 19:27:53
gibt es ein paket für arm-none-eabi-gcc ?
gcc-arm-none-eabi

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: chris1284 am 16 Mai 2017, 06:56:19
Danke Andreas, hat geholfen.
Nun steigt er jedoch mit

Zitat/opt/a-culfw-master/culfw/Devices/MapleCUN/../../clib/rf_native.c:218: undefined reference to `dec2hms_lacrosse'
collect2: error: ld returned 1 exit status
makefile:237: recipe for target 'MapleCUNx4_W5100_BL.elf' failed
make[1]: *** [MapleCUNx4_W5100_BL.elf] Error 1
make[1]: Leaving directory '/opt/a-culfw-master/culfw/Devices/MapleCUN'
makefile:201: recipe for target 'all' failed
make: *** [all] Error 2
aus. bei anderen devices hat es immer gereicht nu in der board.h #define LACROSSE_HMS_EMU   einzufügen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bartman121 am 16 Mai 2017, 06:59:20
Hallo Chris, im makefile fehlt die entsprechende Bibliothek...
SRCS += ../../clib/lacrosse.c

Grüße Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: toensi am 21 Mai 2017, 12:23:38
Hallo,

ich hätte gerne auch sowas : MapleCUL USB-Stick mit zwei CC1101 Transceivern .

Danke und Gruß aus Münster
toensi
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 21 Mai 2017, 18:02:24
Hallo toensi,

Zitat von: toensi am 21 Mai 2017, 12:23:38
ich hätte gerne auch sowas : MapleCUL USB-Stick mit zwei CC1101 Transceivern .
wenn Du schnell bist, siehe hier https://forum.fhem.de/index.php/topic,65998.msg638216.html#msg638216

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 21 Mai 2017, 18:25:20
Hallo Zusammen,

diesmal bin ich etwas ins Stocken geraden und würde mich über Eure Unterstützung freuen:

make TARGET=MapleCULx4 build
make[1]: Entering directory '/home/bananapi/MapleCul/a-culfw-Maple/a-culfw-master/culfw/Devices/MapleCUN'
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -DSTM32F103CBTx -DSTM32F1 -DMapleCULx4  -DSTM32 -DDBGU_UNIT_IN -DUSE_HAL_DRIVER -DSTM32F103xB  -std=c99  -I../MapleCUN -I../../clib -I../../STM32 -I../../STM32/usbd -I../../STM32/utility -I../../STM32/Drivers/STM32F1xx_HAL_Driver/Inc -I../../STM32/Drivers/CMSIS/Include -I../../STM32/Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../../STM32/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc -I../../STM32/Middlewares/ST/STM32_USB_Device_Library/Core/Inc/ -I../../Wiznet/Ethernet -I../../Wiznet/Ethernet/W5100 -I../../Wiznet/Internet -flto -fuse-linker-plugin -Os -DTRACE_LEVEL=4 -g3 -Wall -fmessage-length=0 -ffunction-sections -c  -MMD -MP -MF .dep/main.o.d -c -o main.o main.c
makefile:231: recipe for target 'main.o' failed
make[1]: Leaving directory '/home/bananapi/MapleCul/a-culfw-Maple/a-culfw-master/culfw/Devices/MapleCUN'
makefile:211: recipe for target 'MapleCULx4' failed


Auf einem BananaPi der compile-Versuch nach einem "make clean" bzw. nach der Installation der Arm-Toolchain ...

Hier nach der Anleitung zur Toolchain:
https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/downloads.html (https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/downloads.html)
verfahren ...

Arduino nutzt die Version: 4.8.3-2014q1.

Kennt Ihr das Problem:
Zitat1: /home/bananapi/arm/arm-2008q3/bin/arm-none-eabi-gcc: Syntax error: "(" unexpected"
?

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 22 Mai 2017, 10:48:29
Hier die richtige Toolchain: https://launchpad.net/gcc-arm-embedded (https://launchpad.net/gcc-arm-embedded) hatte das im  culfw-Thread hier (https://forum.fhem.de/index.php/topic,38404.0.html) leider zu spät entdeckt ....

Unter Win10-x64:
Zitatarm-none-eabi-objcopy -O ihex MapleCULx4.elf MapleCULx4.hex
arm-none-eabi-objcopy -O binary MapleCULx4.elf MapleCULx4.bin
arm-none-eabi-size MapleCULx4.elf
   text    data     bss     dec     hex filename
  47420    1844    8888   58152    e328 MapleCULx4.elf
make[1]: Leaving directory `D:/Work_FHEM/_STM32/a-culfw-master/culfw/Devices/MapleCUN'

hat es nach einem make clean dann doch geklappt.  :)

Dann habe ich es von einem "nackten" STM32F103 (ohne Maple-Board) mit Hilfe von Locutus-Platine von der Bestellung + Bestückung bis zur CUL-Firmware geschafft.   :D

Wobei ich sagen muss, dass es mit dem ARM-Cortex-M0 und z. B. einem NXP-LPC (https://www.mikrocontroller.net/articles/LPC-Mikrocontroller)11U35 und LCXpresso irgendwie einfacher ging:
Bin-Datei erzeugen und einfach in ein USB-LW kopiern, welches vom Board erzeugt wird. Reset drücken und das war die gesamte Programmierung.
Irgendwie ist das einfacher ...

ZitatDer STM32F103CBT6 selbst unterstützt kein DFU über USB

Einzelheiten zum Bootloader:
http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-docs/latest/bootloader.html (http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-docs/latest/bootloader.html)
http://wiki.stm32duino.com/index.php?title=Bootloader (http://wiki.stm32duino.com/index.php?title=Bootloader)
https://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/ (https://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/)

Vielen Dank an alle Beteiligten und wieder viele Erkenntnisse gesammelt ....

Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: timtom am 29 Mai 2017, 10:47:51
Bitte nicht schlagen. Aus Unwissenheit eine vielleicht blöde Frage. Aber kann man den MapelCUN eigentlich auch mit der Signalduino-FW flashen, wenn ein C1101 verbaut ist?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 29 Mai 2017, 11:59:01
Zitat von: timtom am 29 Mai 2017, 10:47:51
Bitte nicht schlagen. Aus Unwissenheit eine vielleicht blöde Frage. Aber kann man den MapelCUN eigentlich auch mit der Signalduino-FW flashen, wenn ein C1101 verbaut ist?
Nein.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 29 Mai 2017, 12:10:38
...aber anscheinend haben mache die JeeLink Option erfolgreich aktiviert...

Dazu würde mich die Meinung von Telekatz interessieren ob das gut / schlecht / unklar funktionieren sollte ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 29 Mai 2017, 18:12:05
Es war ja nur die LACROSSE_HMS_EMU Funktion, die aktiviert wurde. Das hat jetzt mit JeeLink nicht direkt was zu tun. Und da in lacrosse.c kein direkter Zugriff auf die Hardware erfolgt, sind da keine größeren Anpassungen an den Maple erforderlich, um zu funktionieren.
Die einzigste Anpassung die nötig wäre, ist vor der Ausgabe der Nachricht ein Aufruf der MULTICC_PREFIX() Funktion einzubauen. Ansonsten könnte die Nachricht in FHEM am falschen CUL eintreffen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 29 Mai 2017, 19:36:12
Ahh, Ok. Danke !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 04 Juni 2017, 17:52:43
Für Locutus MapleCUL-Version habe ich hier ein 3D-Druck-Gehäuse konzipiert:
https://forum.fhem.de/index.php/topic,72777.msg643813.html#msg643813 (https://forum.fhem.de/index.php/topic,72777.msg643813.html#msg643813)

Noch ein Hinweis zum Aufbau des CUL:
Habe zu spät gesehen, dass ich beide CC1101 "falschherum" eingebaut hatte.
Das lässt sich mit FHM auch im Nachhinein einfach mit dem Attribut "freq"  des MapleCULs lösen und funktioniert.   :D
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 04 Juni 2017, 21:41:56
Zitat von: juergs am 04 Juni 2017, 17:52:43
Noch ein Hinweis zum Aufbau des CUL:
Habe zu spät gesehen, dass ich beide CC1101 "falschherum" eingebaut hatte.
"Falschherum" heißt, den 433 MHz auf die Position vom 868 MHz und umgekehrt?

Danke + Gruß

PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 04 Juni 2017, 21:43:44
Ja genau.  :)

Einmal nicht aufgepasst ... Die Dinger lassen sich schlecht auslöten ... 
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 Juni 2017, 22:58:11
Beides geht.

- Mit Heißluft oder viel Zinn über alle Pins auslöten
- oder einfach die Attribute setzen !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 04 Juni 2017, 23:35:47
Zitat von: Ranseyer am 04 Juni 2017, 22:58:11
Beides geht:
- Mit Heißluft oder viel Zinn über alle Pins auslöten

... dann hätte ich vorher doch noch die /CS getauscht oder umgelötet.  :)

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: FLOK am 07 Juni 2017, 15:53:50
Hallo zusammen,
ich habe meinen mapleCUNx4 von "Ranseyer" bekommen (an dieser Stelle Vielen Dank, auch für deine Starthilfe  :) )
Nun habe ich allerdings doch ein Thema, bzw. vielleicht einfach Unverständnis...

Nachdem ich den mapleCUN1 definiert habe:
Zitat
define mapleCUN1 CUL 172.16.0.12:2323 0815
attr mapleCUN1 addvaltrigger 1
attr mapleCUN1 rfmode MAX
attr mapleCUN1 room MAPLE
attr mapleCUN1 verbose 2

Habe ich einen CUL_MAX angelegt:
Zitat
define CULMAX CUL_MAX 123456
attr CULMAX IODev mapleCUN1
attr CULMAX room MAPLE

Ist das korrekt und nötig?

Ich habe mich bei der Geschichte an meinem nanocul orientiert, denn da war es ja auch so:
1. USB Device mit FTDI Adresse anlegen
2. CUL_MAX definieren

Ich frage, weil mein FHEM ständig ein neues Max Gerät anlegt (autocreate):

Zitat
Internals:
   CULMAX_MSGCNT 16
   CULMAX_TIME 2017-06-07 15:50:38
   DEF        WallMountedThermostat 123456
   IODev      CULMAX
   LASTInputDev CULMAX
   MSGCNT     16
   NAME       MAX_123456
   NR         177
   RSSI       -29.5
   STATE      17.0 °C
   TYPE       MAX
   addr       123456
   type       WallMountedThermostat
   Readings:
     2017-06-07 15:50:38   RSSI            -29.5
     2017-06-07 14:09:20   TimeInformationHour 3
     2017-06-07 15:50:38   desiredTemperature 17.0
     2017-06-07 13:56:45   groupid         0
     2017-06-07 15:50:38   mode            manual
     2017-06-07 15:50:38   state           17.0 °C
   Internals:
     interfaces thermostat;temperature;battery
Attributes:
   IODev      CULMAX
   room       MAX

Ich besitze kein WallMountedThermostat, und die ID (123456) ist garantiert auch keine von MAX!  ???
Zudem sind im zugehörigen LOG-File Daten, die zu dem eines meiner Heizungsthermostaten passen...

Ne Idee, was da passiert?
Wenn ich das Gerät lösche, kommt es irgendwann wieder.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 07 Juni 2017, 17:36:14
"... und noch 'ne Platine"  :o

Hallo zusammen,

ich möchte folgenden Aufbau des mapleCUx:
3x Radio (868 MHz, 433 MHz, 868 MHz, die ersten beiden für slowrf)
1x 1-wire (statt 4. Radio)
1x HMUART Platine für HomeMatic
1x MySensors Gateway
1x LAN Anbindung optional (als Ersatz für meinen CUNO v2).

Und das Ganze soll in ein vernünftiges Gehäuse eingebaut werden. Da mir der mapleMini zuviel Platz braucht, habe ich das Ganze genommen und diskret auf die Platine gepackt. Hat (hoffentlich) den Vorteil, dass ich platzmäßig mit den Radios etwas flexibler bin.
Ich habe als Basis eine Platine von Ranseyer genommen und bei locutus 2-fach Transceiver die Beschaltung des STM abgekupfert. Da ich mich mit dem STM Prozessor nicht wirklich auskenne, würde ich mich freuen, wenn jemand kritisch über meinen Schaltplan schauen könnte:
- der linke Teil neben dem Rahmen wird entfallen, ebenfalls die langen Stiftleisten rechts in der Mitte
- wozu ist im original mapleMini das Signal DISC (ich vermute, da wird irgend eine Impedanz auf USBDM geschaltet), braucht man das?
- wofür ist der Bootjumper bei locutus?
- warum ist im originalen mapleMini PB8 und BOOT0 parallel geschaltet, bei locutus PB8 offen?
Wenn jemand generell noch mal über die Verdrahtung schauen könnte, wäre das echt toll.

Danke schon mal im voraus.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 07 Juni 2017, 19:04:34
Hi Peter,

da du auf nem alten Stand von mir aufsetzt solltest du mal mein Changelog lesen ob dich da etwas betrifft: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/History-Bugs.txt

Mal ein paar Gedanken:
-Der Reset Button ist aus meiner Sicht vollkommen unnötig. Den ARM Debugger nutze ich nicht und auch keiner der User meiner Platinen bekannt...
-Im NRF24L01 ohne Möglichkeit für LNA+PA sehe ich auch nur begrenzt Sinn.
-Nutzung von OneWire auf meinen Platinen habe ich auch noch nicht gehört.
-MySensory geht nun auch mit RFM69 auf günstigeren Frequenzen.

Ich kann man gelegentlich ein Foto posten wie meine Hauptnutzung aktuell so aussieht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Juni 2017, 19:59:52
Zitat von: PeMue am 07 Juni 2017, 17:36:14
- wozu ist im original mapleMini das Signal DISC (ich vermute, da wird irgend eine Impedanz auf USBDM geschaltet), braucht man das?
Mit DISC kann man den USB Host dazu bringen, die USB Verbindung zu trennen und wieder neu zu verbinden. Das ist für den Bootloader wichtig, da der sich als DFU Gerät am USB Host meldet, die Firmware dann aber z.B. ein neue Verbindung als CDC Gerät aufbauen möchte.

Zitat von: PeMue am 07 Juni 2017, 17:36:14
- wofür ist der Bootjumper bei locutus?
Kann man weglassen und direkt auf GND legen. Je nach Pegel von BOOT0 und BOOT1 kann man festlegen, dass der STM32 vom Flash, SRAM oder internen Bootloader starten soll. Bei BOOT1=0 und BOOT0=1 wird der Bootloader gestartet, BOOT1=1 und BOOT0=1 wird vom SRAM gestartet. Vom Flash wird gestartet bei BOOT0=0.

Zitat von: PeMue am 07 Juni 2017, 17:36:14
- warum ist im originalen mapleMini PB8 und BOOT0 parallel geschaltet, bei locutus PB8 offen?
PB8 wird beim Maple Bootloader dazu verwendet, nach dem Booten im Bootloader bleiben zu können. Außerdem kann man dadurch den Taster auch noch für eigene Zwecke nutzen. Ansonsten wäre der nur zum starten des internen Bootloaders zu gebrauchen.


1-Wire hatte ich eigentlich anstelle vom dritten Transceiver vorgesehen. Dort sind auch die I2C Pins vom STM32. Außerdem sind diese Pins auch 5V tolerant. Den DS2482 würde ich dann auch mit 5V betreiben.
Dem 1-wire Anschluss würde ich noch eine Polyswitch für die 5V spendieren.
Für die Abblockkondensatoren am STM32F1 sieht Referenzschaltung im Datenblatt auch andere Werte vor. (Datenblatt 5.1.3 (http://www.st.com/resource/en/datasheet/CD00161566.pdf))
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 Juni 2017, 20:07:49
Hallo Peter,

hier sieht man die DISC-USB-Beschaltung dazu:
MapleMini-Schematic (https://forum.arduino.cc/index.php?action=dlattach;topic=365438.0;attach=147262)
evtl. hier noch eine Variante:
S64DIL-Maple (http://reusch-elektronik.reworld.eu/en/products/s64dil-405/index.htm)

Hier noch eine Kurzfassung:
AN2586 (http://www.st.com/content/ccc/resource/technical/document/application_note/6c/a3/24/49/a5/d4/4a/db/CD00164185.pdf/files/CD00164185.pdf/jcr:content/translations/en.CD00164185.pdf)

dann bekommt man fast auch noch den CC1101 unter?  ;) ;) ;)

johanson-balun-868MHz (http://de.farnell.com/johanson-technology/0868bm15c0001e/balun/dp/2148532?mckv=sWdgCWYjo_dc%7Cpcrid%7C76709463183%7Ckword%7C0868bm15c0001e%7Cmatch%7Cp%7Cplid%7C&CMP=KNC-GDE-GEN-SKU-MDC&gclid=CP3O88KzrNQCFW0R0wod-68GIA)
johanson-balun-433MHz (http://de.farnell.com/johanson-technology/0433bm15a0001e/balun-433mhz/dp/2148531)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 07 Juni 2017, 21:30:01
Wollte mal wieder flashen und mein maple mini weigerte sich.
Hab nun aber wirklich die Lösung :-)
Man muss noch Boot1 mit GND verbinden beim Mini. Dann gehts auf anhieb!

Beschrieben ist das hier:
http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-docs/0.0.12/bootloader.html
Step 2: Connect Maple Serial1 to your computer. There are a variety of ways of doing this. We use Sparkfun's FTDI breakout boards, but you could use another Maple, an Arduino, etc. – anything that allows your computer to communicate with the Maple you want to reprogram over a serial interface.

If you do use an FTDI breakout board, first make sure your Maple is disconnected from an external power source, be it battery, USB, or barrel jack. Then, connect the FTDI board's TX pin to Serial1's RX pin (labeled "RX1" on the silkscreen), FTDI RX to Serial1 TX (labeled "TX1"), FTDI ground to ground (labeled GND), and its 3.3V pin to Vin. On Maple Mini, you will also need to tie BOOT1 (pin 2) to ground.

More information on Serial1 is available here.

At this point, you're ready to plug the FTDI board into your computer (via USB).

Step 3: Run the built-in hardware serial bootloader[2]. Accomplish this using the following steps:

Press and hold the reset and BUT buttons.
Release the reset button without releasing BUT.
Release BUT.
At this point, if you followed the instructions correctly, the board will appear unresponsive – the LED won't blink, etc. Don't worry. This is the expected behavior for the serial bootloader.

Do not confuse the above steps, which run the built-in serial bootloader, with the steps for perpetual bootloader mode.


Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Capricornus73 am 07 Juni 2017, 21:45:07
Zitat von: stefanru am 07 Juni 2017, 21:30:01
Wollte mal wieder flashen und mein maple mini weigerte sich.
Hab nun aber wirklich die Lösung :-)
Man muss noch Boot1 mit GND verbinden beim Mini. Dann gehts auf anhieb!

Beschrieben ist das hier:
http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-docs/0.0.12/bootloader.html
Step 2: Connect Maple Serial1 to your computer. There are a variety of ways of doing this. We use Sparkfun's FTDI breakout boards, but you could use another Maple, an Arduino, etc. – anything that allows your computer to communicate with the Maple you want to reprogram over a serial interface.

If you do use an FTDI breakout board, first make sure your Maple is disconnected from an external power source, be it battery, USB, or barrel jack. Then, connect the FTDI board's TX pin to Serial1's RX pin (labeled "RX1" on the silkscreen), FTDI RX to Serial1 TX (labeled "TX1"), FTDI ground to ground (labeled GND), and its 3.3V pin to Vin. On Maple Mini, you will also need to tie BOOT1 (pin 2) to ground.

More information on Serial1 is available here.

At this point, you're ready to plug the FTDI board into your computer (via USB).

Step 3: Run the built-in hardware serial bootloader[2]. Accomplish this using the following steps:

Press and hold the reset and BUT buttons.
Release the reset button without releasing BUT.
Release BUT.
At this point, if you followed the instructions correctly, the board will appear unresponsive – the LED won't blink, etc. Don't worry. This is the expected behavior for the serial bootloader.

Do not confuse the above steps, which run the built-in serial bootloader, with the steps for perpetual bootloader mode.


Gruß,
Stefan

Hallo Stefan,

genau das habe ich in meinem Post #287 beschrieben und mir deshalb zum Flashen ein Jumper eingebaut  ;D


Gruß Jörg
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 07 Juni 2017, 21:54:07
Oh mist,

ich breche mir hier jedes mal die Finger beim Flashen.
Deinen Post hatte ich übersehen, trotzdem Danke :-)

Habe gerade neu gebaut und mir ist aufgefallen dass es nur noch den mapleCUN gibt in der a-culfw, keinen mapleCUL.
Das ist wahrscheinlich ja auch wurscht.
Nach dem make finde ich nun aber 2 bin Dateien.
MapleCUNx4_W5100_BL.bin
MapleCUNx4_W5500_BL.bin

Welche flashe ich nun auf einen mapleCUL? Also kein Netzwerk vorgesehen.
Wahrscheinlich egal, oder?

Danke und Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Capricornus73 am 07 Juni 2017, 22:04:51
Zitat von: stefanru am 07 Juni 2017, 21:54:07
Oh mist,

ich breche mir hier jedes mal die Finger beim Flashen.
Deinen Post hatte ich übersehen, trotzdem Danke :-)

Habe gerade neu gebaut und mir ist aufgefallen dass es nur noch den mapleCUN gibt in der a-culfw, keinen mapleCUL.
Das ist wahrscheinlich ja auch wurscht.
Nach dem make finde ich nun aber 2 bin Dateien.
MapleCUNx4_W5100_BL.bin
MapleCUNx4_W5500_BL.bin

Welche flashe ich nun auf einen mapleCUL? Also kein Netzwerk vorgesehen.
Wahrscheinlich egal, oder?

Danke und Gruß,
Stefan

Hallo Stefan,

wenn kein Netzwerk vorgesehen ist dann ist es egal welche Du flashst! Die Dateien sind nur unterschiedlich, weil es zwei Netzwerkadapter LAN gibt, welche mit der Firmware unterstützt werden (W5100 oder W5100). Für den Betrieb über USB ist es egal.


Gruß Jörg
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 Juni 2017, 22:09:17
Bei mir haben beide nicht  (MapleCUL) funktioniert:
MapleCUNx4_W5100_BL.bin
MapleCUNx4_W5500_BL.bin

Die MapleCUL4x.bin von hier:
https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507 (https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507)
funktioniert als MapleCUL.

Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 07 Juni 2017, 22:13:10
Hab ich auch gerade gemerkt, was ist da los?
Habe nun beide mehrmals versucht und nach dem Flashen abzeihen vom USB neu anstecken macht der Maple nix.
Keine LED, garnix. Wird auch nicht als USB device erkannt.

Ich verstehe das nicht. Konnte bisher immer selbst bauen.
Was geht denn da jetzt in die Hose?

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 07 Juni 2017, 22:19:45
Keine Ahnung was ihr da genau macht.

Genau nach der Anleitung hat es bei mir schon X-Mal geklappt. (Ich verwende allerdings nur noch W5500 LAN, zum W5100 kann ich nichts sagen)

-Den Bootloader tauschen per Debug-Port und USB-Adapter (Außeren Button halten, und dann Spannung anlegen)
-Dann erst das fertige Firmware Binary per USB-Anschluss am MAPLE flashen (Keinesfalls das Binary für Bootloader direkt flashen, evtl ist das euer Problem)

Die beiden Steps müssen unbedingt passend zueinander gemacht werden so dass die Adressen in der Firmware passend zum Bootloader sind.

Grüße
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Juni 2017, 22:24:45
Zitat von: juergs am 07 Juni 2017, 22:09:17
Bei mir haben beide nicht  (MapleCUL) funktioniert:
MapleCUNx4_W5100_BL.bin
MapleCUNx4_W5500_BL.bin

Die MapleCUL4x.bin von hier:
https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507 (https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507)
funktioniert als MapleCUL.

Jürgen
Die Dateien mit "_BL.bin" am Enden sind für den Maple mini Bootloader. MapleCUL4x.bin ist für das direkt flashen ohne Maple mini Bootloader.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 Juni 2017, 22:24:59
Hallo Ranseyer,

Unterschied CUN & CUL-Platine?

Ich beziehe mich nur auf Locutus 2*CC1101-Platine ohne LAN.

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 Juni 2017, 22:28:18
Zitat von: Telekatz am 07 Juni 2017, 22:24:45
Die Dateien mit "_BL.bin" am Enden sind für den Maple mini Bootloader. MapleCUL4x.bin ist für das direkt flashen ohne Maple mini Bootloader.

Jetzt!  Hatte die Platinen mit gekauften CPUs bestückt, ohne Maple-BL.

Danke, hatte mich auch gewundert.

Noch eine Frage: Geht der DFU-Bootloader wirklich nicht auf dem F103?

Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 07 Juni 2017, 22:32:29
Hups,

kannst du mir das nochmal erläutern?
"-Den Bootloader tauschen per Debug-Port und USB-Adapter (Außeren Button halten, und dann Spannung anlegen)
-Dann erst das fertige Firmware Binary per USB-Anschluss am MAPLE flashen (Keinesfalls das Binary für Bootloader direkt flashen, evtl ist das euer Problem)"

Ich flashe mit FTDI und dem Demonstrator.
Habe einfach das Bin, also MapleCUNx4_W5500_BL.bin geflasht.
Wie muss ich denn nun vorgehen? Habe doch nur das File vom Build.

Sorry und Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 Juni 2017, 22:36:41
Zitat von: Telekatz am 07 Juni 2017, 22:24:45
Die Dateien mit "_BL.bin" am Enden sind für den Maple mini Bootloader. MapleCUL4x.bin ist für das direkt flashen ohne Maple mini Bootloader.

Hängt wohl von der eingesetzten Platine ab.
Ich habe die Binary, die ich dort angehängt habe ...
Zitat von: juergs am 07 Juni 2017, 22:09:17
Bei mir haben beide nicht  (MapleCUL) funktioniert:
MapleCUNx4_W5100_BL.bin
MapleCUNx4_W5500_BL.bin

Die MapleCUL4x.bin von hier:
https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507 (https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507)
funktioniert als MapleCUL.

Jürgen
ohne _BL auch auf den MapleMini mit dem Demonstrator geflasht und geht ebenfalls.
Wäre nur zu klären, ob ich irgendwann bei Bedarf den MapleMini-BL wieder drauf bekomme ...

Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Juni 2017, 22:42:02
Zitat von: juergs am 07 Juni 2017, 22:28:18
Jetzt!  Hatte die Platinen mit gekauften CPUs bestückt, ohne Maple-BL.

Danke, hatte mich auch gewundert.

Noch eine Frage: Geht der DFU-Bootloader wirklich nicht auf dem F103?

Jürgen
Der STM32F1 hat keinen integrierten DFU Bootloader. Für DFU braucht man den Maple mini Bootloader.

Zitat von: juergs am 07 Juni 2017, 22:36:41
Wäre nur zu klären, ob ich den MapleMini-BL wieder drauf bekomme ...
Der Maple mini Bootloader wird genauso geflasht wie die MapleCUL4x.bin.
Anleitung zu Flashen: https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 07 Juni 2017, 22:49:16
Ok, wieder was gelernt.
D.h. Ich muss jetzt einmalig mim Demonstrator den mini Bootloader flashen und kann dann per USB und DFU-Util immer die MapleCUNx4_W5500_BL.bin drauf flashen?

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 Juni 2017, 22:57:57
http://wiki.stm32duino.com/index.php?title=Bootloader (http://wiki.stm32duino.com/index.php?title=Bootloader)

Ich benutze diesen hier:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin
von hier:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 07 Juni 2017, 23:07:17
Also heut bekomm ich nix hin....

Habe nun den maple_mini_boot20.bin geflashed.
Den Maple an den Rapberry angeschlossen. Reset gedrückt. LED Blinkt mit 4HZ.

Ein lsusb liefert:
Bus 001 Device 073: ID 1eaf:0003

Ein flashen mit:
dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: Cannot open DFU device 1eaf:0003
dfu-util: No DFU capable USB device available

Kann mir hier nochmal jemand unter die Arme greifen?

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 Juni 2017, 23:12:49
dfu-util ist doch die Arduino Variante zum Flashen ...
Mit dem stm32duino-BL von einem Post darüber sollte das gehen...  :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 07 Juni 2017, 23:18:48
Ok, danke.
Das verstehe ich jetzt aber nicht.
In der Anleitung vom Maple steht dfu-util.
Ich versuche dann dein tool mal morgen.
Für heute ist Schluss.

Danke und Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 08 Juni 2017, 08:49:40
Zitat von: stefanru am 07 Juni 2017, 23:07:17
Habe nun den maple_mini_boot20.bin geflashed.
Den Maple an den Rapberry angeschlossen.
Reset gedrückt. LED Blinkt mit 4HZ.

Reset alleine reicht zum Flashen nicht aus.
Zuerst den Boot-Button drücken, dann Reset und dann Reset loslassen und Boot-Button gedrückt halten.
Dabei sollte die blinkende LED aus sein, dann befindet sich der Maple im Booloader Modus.
dfu-util erwartet mehere (3) serielle Schnittstellen, die der Maple im BL-Modus aufspannt.
Das aber nur mit dem "richtigen" Bootloader. Ob das der Maple-BL auch so akzeptiert kann ich leider nicht sagen,
da diese Konstellation bei mir nicht aktiv ist und ich eigentlich nur über die serielle Schnittstelle programmiere.
dfu-util kommt nur mit der Arduino-IDE zum Einsatz.

Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 08 Juni 2017, 09:28:52
Danke Jürgen.

Dann ist die Anleitung aber falsch.

Da steht:
"a-culfw flashen

Reset am Maple Mini drücken.
Während die LED schnell blinkt (ca. 4Hz) dfu-util starten: dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin
Hinweis: Für einen MapleCUL ist es egal, ob die Datei MapleCUNx4_W5100_BL.bin oder MapleCUNx4_W5500_BL.bin verwendet wird."

Das funktioniert so nicht.

Ich habe auch noch keine wirkliche Ahnung wie das nun gehen soll.
Dachte dieses But und Reset drücken ist zum Bootloader flashen per Demonstrator.

Danach müsste ich eigentlich, zumindest laut beschreibung, Einfach die Maple_XXX_BL.bin flashen können über den USB am Maple.
Das klappt aber mit oben genanntem fehler nicht...

Gruß,
Stefan

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 08 Juni 2017, 09:43:17
ZitatThe Maple Mini is pretty much plug-and-play, like any Arduino board:

    Buy a Maple Mini clone
    Install the STM32duino core
    Plug in the board

            On Windows 10 the bootloader driver will install automatically
            With no sketch loaded, the bootloader will cause the LED to blink rapidly
            Note that there are no power or serial LEDs, only a user LED

    Select "Maple Mini" under 'Tools → Board' in the Arduino IDE, and select the correct COM port
    Under 'File → Examples → A_STM32_Examples → Digital' select "Blink"
    Hit upload

            The LED should now blink more slowly

No external programmers or hardware modifications are needed. For the blink sketch you won't even need pin headers.
Mit dem korrekten BL (und der richtigen COM-Port Einstellung?) sollte es normal so gehen.

Wie ist Deine Parameter Zeile von dfu-util?

Ging zumindest bei mir so   ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 08 Juni 2017, 10:00:57
Flashen sollten man (außer man weiss 200% was man tut) nur mit den Tools aus der Anleitung.

Das was ihr so tut ist mir viel zu kompliziert.

Besser: Das Teil an eine Linux-Kiste hängen.

-Einfach eins der 1*er Scripte aus der Anlage starten und an den Text halten (dazu braucht man bei meiner Methode auch nur den vorderen = Bot-Button siehe Aufforderung am Bildschirm, + eine wirklich stabile Verbindung zum Debug Port RX+TX gekreuzt)
-Dann das zweier Skript starten 



Und vorher so viele Pakete installieren / kompileren +Firmware besorgen dass keine Fehler kommen: stm32flash, dfu-util
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 08 Juni 2017, 10:26:13
... oder so.  :)

Ist boot1 vom Maple mit gnd verbunden?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 08 Juni 2017, 11:24:17
Hi,

ok dann versuche ich es mal nur auf dem Raspberry mit deinen Skripten.
Eigentlich habe ich mich nun zum Schluss schon an die Anleitung gehalten.

Habe aber die maple_mini_boot20.bin mit dem FTDI in Windows per Demonstartor geflashed.
Da bin ich eigentlich der Meinung das hat gut geklappt.

Danach am Raspberry dann über den USB Port am Maple:
sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin

Leider hat das nicht mehr geklappt.

Danke auf jedenfall für die Anleitungen und Ideen.
Ich werde das nochaml bei mior ausprobieren und berichten wenn ich es denn löse woran genau das Problem lag.

Vielen Dank und Gruß,
Stefan

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Juni 2017, 11:35:02
Zitat von: stefanru am 08 Juni 2017, 11:24:17
Danach am Raspberry dann über den USB Port am Maple:
sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin
Wieso hast du es mit dem DFU-UTIL nicht auch noch in Windows probiert?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 08 Juni 2017, 11:54:00
Hallo Ranseyer, Telekatz und juergs,

Danke für Eure Hinweise, ich habe die mal eingebaut:
Zitat von: Ranseyer am 07 Juni 2017, 19:04:34
Der Reset Button ist aus meiner Sicht vollkommen unnötig. Den ARM Debugger nutze ich nicht und auch keiner der User meiner Platinen bekannt.
Ist entfallen, Eagle motzt halt über die nur einfach kontaktierten Leitungen  :P

Zitat von: Ranseyer am 07 Juni 2017, 19:04:34
Im NRF24L01 ohne Möglichkeit für LNA+PA sehe ich auch nur begrenzt Sinn.
Es ist der mit LNA+PA, nur sieht man das im Symbol nicht  ;)

Zitat von: Telekatz am 07 Juni 2017, 19:59:52
Mit DISC kann man den USB Host dazu bringen, die USB Verbindung zu trennen und wieder neu zu verbinden.
Ok, habe ich weggelassen, nur das Signal ist noch da (und Eagle meckert, dass nur eine Leitung angeschlossen ist  ;)).

Zitat von: Telekatz am 07 Juni 2017, 19:59:52
Ich habe jetzt einen Lötjumper draufgepackt, der standardmäßig geschlossen sein wird.
Kann man weglassen und direkt auf GND legen. Je nach Pegel von BOOT0 und BOOT1 kann man festlegen, dass der STM32 vom Flash, SRAM oder internen Bootloader starten soll. Bei BOOT1=0 und BOOT0=1 wird der Bootloader gestartet, BOOT1=1 und BOOT0=1 wird vom SRAM gestartet. Vom Flash wird gestartet bei BOOT0=0.
Da habe ich jetzt einen Lötjumper spendiert, der standardmäßig geschlossen sein wird.

Zitat von: Telekatz am 07 Juni 2017, 19:59:52
PB8 wird beim Maple Bootloader dazu verwendet, nach dem Booten im Bootloader bleiben zu können. Außerdem kann man dadurch den Taster auch noch für eigene Zwecke nutzen. Ansonsten wäre der nur zum starten des internen Bootloaders zu gebrauchen.
Ok, ich habe es verstanden. Vermutlich wird es die Firmware nie können, aber es bleibt wie beim maple Mini verbunden.

Zitat von: Telekatz am 07 Juni 2017, 19:59:52
1-Wire hatte ich eigentlich anstelle vom dritten Transceiver vorgesehen. Dort sind auch die I2C Pins vom STM32. Außerdem sind diese Pins auch 5V tolerant. Den DS2482 würde ich dann auch mit 5V betreiben. Dem 1-wire Anschluss würde ich noch eine Polyswitch für die 5V spendieren.
Ist geändert. Jetzt brauche ich nur noch einen vernünftigen Stecker: entweder den, den locutus dran hat (3-polig Würth zum klemmen) oder den, den der CUNO dran hat (nicht Standard, aber schön zum Stecken)  :-\

Zitat von: Telekatz am 07 Juni 2017, 19:59:52
Für die Abblockkondensatoren am STM32F1 sieht Referenzschaltung im Datenblatt auch andere Werte vor. (Datenblatt 5.1.3 (http://www.st.com/resource/en/datasheet/CD00161566.pdf))
Müsste vermutlich Kap. 5.1.6 sein, aber die maple Mini Jungs halten sich auch nicht daran. Ich habe mal 2x100 nF und 4.7 µF spendiert, die 5x 100 nF scheinen mir etwas übertrieben.

Zitat von: juergs am 07 Juni 2017, 20:07:49
Dann bekommt man fast auch noch den CC1101 unter?  ;) ;) ;)
Das mache ich nicht, da mir der HF Kreis doch vom Layout her zu heikel ist.

Ich habe den aktuellen Schaltplan mal angehängt.

Ich sehe schon, mit Eurer Diskutiererei um den Bootloader: ich sollte mir mal meinen maple Mini hernehmen und den Bootloader flashen und die Firmware draufpacken  :o

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Juni 2017, 12:22:12
Zitat von: PeMue am 08 Juni 2017, 11:54:00
Müsste vermutlich Kap. 5.1.6 sein, aber die maple Mini Jungs halten sich auch nicht daran. Ich habe mal 2x100 nF und 4.7 µF spendiert, die 5x 100 nF scheinen mir etwas übertrieben.
Wie viele Kondensatoren man braucht hängt davon ab, welche Gehäusevariante man vom STM32F103 hat, denn die haben eine unterschiedliche Anzahl von Versorgungspins. Beim STM32F103CBT6 bekommt jeder der drei VDD_x Pins einen 100nF Kondensator und VDD_3 noch zusätzlich einen 4,7µF Kondensator. Und an VDD_A 10nF und 1µF.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 08 Juni 2017, 13:49:44
@Telekatz: Ich hab halt Git und Make auf dem Rapberry eingerichtet. War für mich der einfachste Weg.

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 08 Juni 2017, 21:08:17
Hi,

so ich habe jetzt nochmal 2 stunden alle wege probiert.
Jeweils genau an die Anleitung gehalten.

Mit dfu-util und stm32flash auf windows,
mit dfu-util und stm32flash auf dem raspberry.

Exakt nach anleitung und mit den Skripten was ja aber auch das gleiche ist.

Immer das selbe problem.
Ich bekomme mit stm32flash ohne Probleme das  maple_mini_boot20.bin geflashed. Habe es wie in der anleitung beschrieben von hier:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/STM32F1/binaries/maple_mini_boot20.bin
Hierzu schließe ich FTDI RX/TX getauscht VCC und GND und Boot1 an GND. BUT Taste beim Einstecken gedrückt halten.

Versuche ich dann mit dfu-util von hier:
http://dfu-util.sourceforge.net/

das MapleCUNx4_W5500_BL.bin zu flashen sagt er
Cannot open DFU device 1eaf:0003
No DFU capable USB device available

Auch ein dfu-util --list  ergibt Cannot open DFU device 1eaf:0003.
Das device 1eaf:0003 wird bei lsusb angezeigt

Hier verstehe ich es so dass nun das bin über den Maple Bootloader geflashed wird also über den USB Anschluss am Maple nicht über den FTDI.
Zur sicherheit habe ich alle Varianten Probiert mit eingestecktem FTDI ohne mit BOOT1 an GND und ohne. Nichts.

Hat jemand noch eine Idee?

Gruß,
Stefan

Ich habe wirklich alles genau nach anleitung durchgeführt.


P.S.:
Flashe ich das MapleCULx4.bin direkt per STM32flash geht das... Leider ist das ja keine Lösung will mein selbst gebautes Flashen.
Ist es möglich so ein File ohne _BL selbst zu bauen damit ich es direkt flashen kann?

Hat das einen Nachteil?



Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Juni 2017, 21:53:11
Eventuell das mal ausprobieren: http://stm32duino.com/viewtopic.php?t=353 (http://stm32duino.com/viewtopic.php?t=353)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 08 Juni 2017, 22:03:26
Heureka,

nach dem ich mich nun durch die ganzen Seiten gewühlt hab in denen es um den Bootloader geht und alles ausprobiert habe hat eine Sache geholfen.
Dieser zadig_2.2.exe USB treiber für WinUSB.
Damit war es mir dann sofort möglich dfu-util zu benutzen.

Das fehlt aber komplett in der Anleitung.
Ich habe jetzt nach 2 Tagen rumprobieren erstmal keinen Nerv mehr noch rauszufinden was man beim Rapberry noch tuen muss damit dfu-util funzt.

Eins ist klar das Flashen des Bootloaders mit stm32flash oder Demonstrator hat immer geklappt.
Die Erkennung des DFU devices ist das problem und geht wohl nur mit zusätzlichen treibern da dfu ein eigenes USB Protokoll ist.

Vielen Dank für die vielen Tips.

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Juni 2017, 22:14:58
Habs gerade auf einem Raspberry probiert. Scheint wohl ein Problem mit den Rechten zu sein. Mit "sudo dfu-util......" hat es funktioniert.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 08 Juni 2017, 22:17:37
Ja, Du brauchst libusb dazu. Das hat dir der Zadig-Treiber-Wrapper zur Verfügung gestellt.

Aber generell: Ich hatte auch Probleme beim ersten Mal Flashen insbesondere, wenn die Erfahrung dazu fehlt, aber in dieser Art ... Hmmmm....

Wenn Du den Bootloader drauf gebracht hast, dann wäre doch auch ein Flashen mit FTDI + Demonstrator für das Anwendungsprogramm möglich gewesen?
Oder sehe ich da was falsch.

Außerdem, zur Vorgehensweise: ich vermute Telekatz hat den Wortlaut Deiner Fehlermeldung 1:1 in Google eingegeben,
der Link zur Lösung unter Linux war der erste Treffer, den ich auch bekommen habe .... 
Das wäre doch ein Ansporn beim nächsten Problem mal auch so vorzugehen ? 
Die Probleme hatten vorher auch schon Tausende andere .... ;)

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 08 Juni 2017, 22:46:11
Hmmm, sollte ich wirklich ohne sudo gearbeitet haben auf dem Raspberry.
Das schau ich bei Gelegenheit nach.

Sorry ich google normalerweise immer, ich glaube das wissen die Leute die mit mir hier zu tun hatten.
Gestern nach 4 Stunden rum flashen habe ich das wohl nicht mehr so genau genommen und einfach auf Hilfe gehofft.

Ein Verweis in der Doku auf den Treiber könnte aber nicht schaden denk ich.

Vielen Dank und Gruß,
Stefan
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 08 Juni 2017, 22:56:44
Stefan,
ich finde es super und Deine Tests und Ergebnisse sind hier auch wertvoll! Ich persönlich habe im ersten Anlauf unter Windows die gleiche Erfahrung gemacht.

Zunächst war der Treiber zu neu und hat den Maple Mini immer nur mit Ausrufezeichen im Gerätemanager angezeigt. (Lösung wegen des China Maple Mini Clon: Downgrade des Win Treibers!)
Danach habe ich per Arduino IDE den Bootpatcher installiert und danach auf dem Maple Mini ausgeführt (Inklusive y drücken auf der Serielle Konsole). Somit ist der richtige Bootloader drauf.

Aber danach habe ich es nicht geschafft über RX/TX den Maple anzusprechen oder über USB weiter zu flashen.

Jetzt schau ich mir den Zadig Treiber auch noch mal an.

Vielleicht finden wir ja doch einen Weg, ganz ohne FTDI Maples zu nutzen ;-)

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 08 Juni 2017, 23:03:23
Bei Windows muss man sich halt beschäftigen mit
- HW-Problemen
- SW-Problemen
- Menschliche Fehler
- Treiber-Problemen

Zumindest der letzte Punkt fällt in diesem Fall unter Linux weg.

Was ich daraus lerne: Wir können die Doku ggf. noch verbessern.
(Ehrlich gesagt kann ich mich nicht mehr erinnern die stlink und dfu-util auf den Rechner gekommen sind. Mindestens eins musste ich selbst kompilieren, und natürlich bei beiden die Doku lesen)

(((Oder auf den schlechteren aber schon vorhandenen USB-Bootloader schwenken um den ersten Schritt zu sparen)))
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 08 Juni 2017, 23:09:19
Wie gesagt, danke für die Hilfe und die tolle Arbeit hier!

Und am Schluss funktioniert es jetzt ja.

@Ranseyer: Kannst du mir bitte noch die Frag im Verkaufen Thread zur 2fach Platine beantworten. Das wäre mir wirklich eine Hilfe.

Danke!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 Juni 2017, 07:32:15
Hallo zusammen,

ich habe den einfach Transceiver von locutus an meinen Raspberry Pi angeschlossen (ohne Netzwerk Transceiver) und bekomme regelmäßig folgende Meldung mit

tail -f /var/log/syslog

Jun  9 07:24:22 PMRPI03 kernel: [3952458.309772] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:22 PMRPI03 kernel: [3952458.309789] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:22 PMRPI03 kernel: [3952458.309805] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:22 PMRPI03 kernel: [3952458.311543] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:22 PMRPI03 kernel: [3952458.314917] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:22 PMRPI03 kernel: [3952458.317668] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:24 PMRPI03 kernel: [3952460.262660] usb 1-1.5: USB disconnect, device number 111
Jun  9 07:24:24 PMRPI03 kernel: [3952460.501911] usb 1-1.5: new full-speed USB device number 112 using dwc_otg
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609647] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609677] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609707] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609725] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609741] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:24 PMRPI03 kernel: [3952460.611459] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:24 PMRPI03 kernel: [3952460.615007] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:24 PMRPI03 kernel: [3952460.617504] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:26 PMRPI03 kernel: [3952462.310928] usb 1-1.5: USB disconnect, device number 112
Jun  9 07:24:26 PMRPI03 kernel: [3952462.551922] usb 1-1.5: new full-speed USB device number 113 using dwc_otg
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659795] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659824] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659866] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659884] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659900] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:26 PMRPI03 kernel: [3952462.661541] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:26 PMRPI03 kernel: [3952462.664032] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:26 PMRPI03 kernel: [3952462.666544] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:28 PMRPI03 kernel: [3952464.615266] usb 1-1.5: USB disconnect, device number 113
Jun  9 07:24:29 PMRPI03 kernel: [3952464.851925] usb 1-1.5: new full-speed USB device number 114 using dwc_otg
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959722] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959751] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959800] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959817] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959833] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:29 PMRPI03 kernel: [3952464.962104] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:29 PMRPI03 kernel: [3952464.964632] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:29 PMRPI03 kernel: [3952464.967124] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:31 PMRPI03 kernel: [3952466.919540] usb 1-1.5: USB disconnect, device number 114
Jun  9 07:24:31 PMRPI03 kernel: [3952467.161906] usb 1-1.5: new full-speed USB device number 115 using dwc_otg
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269655] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269684] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269721] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269739] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269755] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:31 PMRPI03 kernel: [3952467.273869] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:31 PMRPI03 kernel: [3952467.276930] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:31 PMRPI03 kernel: [3952467.280472] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:33 PMRPI03 kernel: [3952468.967826] usb 1-1.5: USB disconnect, device number 115
Jun  9 07:24:33 PMRPI03 kernel: [3952469.281934] usb 1-1.5: new full-speed USB device number 116 using dwc_otg
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389558] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389588] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389620] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389637] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389653] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:33 PMRPI03 kernel: [3952469.391420] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:33 PMRPI03 kernel: [3952469.394933] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:33 PMRPI03 kernel: [3952469.398043] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:35 PMRPI03 kernel: [3952471.272137] usb 1-1.5: USB disconnect, device number 116
Jun  9 07:24:35 PMRPI03 kernel: [3952471.511971] usb 1-1.5: new full-speed USB device number 117 using dwc_otg
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619865] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619895] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619925] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619942] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619958] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:35 PMRPI03 kernel: [3952471.621737] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:35 PMRPI03 kernel: [3952471.624934] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:35 PMRPI03 kernel: [3952471.627597] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:37 PMRPI03 kernel: [3952473.576465] usb 1-1.5: USB disconnect, device number 117

Ist da die falsche Firmware drauf? Beim Resetten blinkt der ab und zu aber ab und zu auch nicht.

Ich habe per
sudo apt-get install dfu-util
dfu-util installiert, aber mit
dfu-util --list
wird nur das Copyright angezeigt.

Danke + Gruß

PeMue
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 09 Juni 2017, 08:08:18
Hi PeMue,

dfu-util -l [-v] [-d vid:pid[,vid:pid]] [-p path] [-c configuration] [-i interface] [-a alt-intf] [-S serial[,serial]]
dfu-util [-v] [-d vid:pid[,vid:pid]] [-p path] [-c configuration] [-i interface] [-a alt-intf] [-S serial[,serial]] [-t size] [-Z size] [-s address] [-R] [-D|-U file]
dfu-util [-hV]

Was sagt den ein:
sudo dfu-util -d 1eaf:0003 --list
bzw.
sudo dfu-util -i /dev/ttyACM0 --list

Vorher muss natürlich fhem das device freigeben oder FHEM schließen.

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 Juni 2017, 08:41:19
Hallo Arnd,

sudo dfu-util -d 1eaf:0003 --list

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Alle anderen Optionen zeigen dasselbe Ergebnis  ???

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 Juni 2017, 08:47:26
Das siebt bei mir so oder so aus:
Zitatartin@martin-wa ~/src/zz_others/Maple-CUN $ sudo dfu-util -d 1eaf:0003 --list
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

martin@martin-wa ~/src/zz_others/Maple-CUN $ sudo dfu-util -d 1eaf:0003 --list
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Found DFU: [1eaf:0003] ver=0201, devnum=10, cfg=1, intf=0, alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=10, cfg=1, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=10, cfg=1, intf=0, alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"
martin@martin-wa ~/src/zz_others/Maple-CUN $


Grund: Beim ersten mal war der MAPLE schon >1 Sekunde eingesteckt.

Mach mal vor dem Einstecken ein "tail -f /var/log/syslog". Damit bekommst du ein Gefühl für den Bootloader.


Spannend ist die die Stelle wo ich manuell drei Leerzeilen eingebaut habe: Der Bootloader wird beendet und es startet die per USB geflashte Applikation

Jun  9 08:44:54 martin-wa kernel: [  938.360949] usb 6-1: new full-speed USB device number 14 using xhci_hcd
Jun  9 08:44:55 martin-wa kernel: [  938.510006] usb 6-1: New USB device found, idVendor=1eaf, idProduct=0003
Jun  9 08:44:55 martin-wa kernel: [  938.510019] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 08:44:55 martin-wa kernel: [  938.510026] usb 6-1: Product: Maple 003
Jun  9 08:44:55 martin-wa kernel: [  938.510032] usb 6-1: Manufacturer: LeafLabs
Jun  9 08:44:55 martin-wa kernel: [  938.510036] usb 6-1: SerialNumber: LLM 003
Jun  9 08:44:55 martin-wa mtp-probe: checking bus 6, device 14: "/sys/devices/pci0000:00/0000:00:10.0/usb6/6-1"
Jun  9 08:44:55 martin-wa mtp-probe: bus: 6, device: 14 was not an MTP device



Jun  9 08:44:56 martin-wa kernel: [  939.942999] usb 6-1: USB disconnect, device number 14
Jun  9 08:44:56 martin-wa kernel: [  940.217071] usb 6-1: new full-speed USB device number 15 using xhci_hcd
Jun  9 08:44:56 martin-wa kernel: [  940.405076] usb 6-1: New USB device found, idVendor=0483, idProduct=5743
Jun  9 08:44:56 martin-wa kernel: [  940.405089] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 08:44:56 martin-wa kernel: [  940.405096] usb 6-1: Product: MapleCUL
Jun  9 08:44:56 martin-wa kernel: [  940.405101] usb 6-1: Manufacturer: STM32
Jun  9 08:44:56 martin-wa kernel: [  940.405106] usb 6-1: SerialNumber: 66345eb0
Jun  9 08:44:56 martin-wa kernel: [  940.405602] usb 6-1: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
Jun  9 08:44:56 martin-wa kernel: [  940.405631] usb 6-1: ep 0x84 - rounding interval to 1024 microframes, ep desc says 2040 microframes
Jun  9 08:44:56 martin-wa kernel: [  940.405654] usb 6-1: ep 0x86 - rounding interval to 1024 microframes, ep desc says 2040 microframes
Jun  9 08:44:56 martin-wa kernel: [  940.408309] cdc_acm 6-1:1.0: ttyACM0: USB ACM device
Jun  9 08:44:56 martin-wa kernel: [  940.411930] cdc_acm 6-1:1.2: ttyACM1: USB ACM device
Jun  9 08:44:56 martin-wa kernel: [  940.415896] cdc_acm 6-1:1.4: ttyACM2: USB ACM device


Wenn du also eine Sekunde nach einstecken ein "lsusb" machst ist das vorn Arndt genannte Device schon wieder weg: 1eaf:0003
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 09 Juni 2017, 09:15:37
Hi PeMue,

kommt da nur das copyright wird garnichts erkannt.
Hast du auf deinem maple den Bootloader maple_mini_boot20.bin schon per stm32flash aufgespielt?

Benutzt du sudo vorm aufruf von dfu-util?

Ich sehe das so entweder hast du den Bootloader nicht drauf, bist nicht im Bootloader Modus oder dfu-util fehlen Berechtigungen / Treiber.
Bin auf Linux da selbst noch am schauen. Kann das am WE nochmal am Raspberry testen.

Hoffe das hilft irgendwie.

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 Juni 2017, 10:04:41
Hallo zusammen,

ich habe locutus' USB Stick, der meldet sich einmal mit
tail -f /var/log/syslog

Jun  9 10:00:50 PMRPI03 kernel: [ 1231.412860] usb 1-1.4: new full-speed USB device number 28 using dwc_otg
Jun  9 10:00:50 PMRPI03 kernel: [ 1231.520497] usb 1-1.4: New USB device found, idVendor=0483, idProduct=5743
Jun  9 10:00:50 PMRPI03 kernel: [ 1231.520525] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 10:00:50 PMRPI03 kernel: [ 1231.520543] usb 1-1.4: Product: MapleCUL
Jun  9 10:00:50 PMRPI03 kernel: [ 1231.520559] usb 1-1.4: Manufacturer: STM32
Jun  9 10:00:50 PMRPI03 kernel: [ 1231.520575] usb 1-1.4: SerialNumber: 12f3a0ac
Jun  9 10:00:50 PMRPI03 kernel: [ 1231.530990] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
Jun  9 10:00:50 PMRPI03 kernel: [ 1231.536145] cdc_acm 1-1.4:1.2: ttyACM1: USB ACM device
Jun  9 10:00:50 PMRPI03 kernel: [ 1231.538856] cdc_acm 1-1.4:1.4: ttyACM2: USB ACM device
Jun  9 10:01:09 PMRPI03 rsyslogd-2007: action 'action 17' suspended, next retry is Fri Jun  9 10:01:39 2017 [try http://www.rsyslog.com/e/2007 ]

Hat dann stabil die drei /dev/ttyACM
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 Juni 2017, 10:14:40
Wenn er sich wirklich nur einmalig meldet, also vor dem Anschließen schon das syslog angezeigt wurde nutzt locutus keinen USB-Bootloader.
Das bedeutet du musst den Bootloader selbst aufspielen*, oder kannst nur Firmwares per USB_Wandler aufspielen, aber die Firmware muss dafür kompiliert sein dass kein Bootloader verwendet wird. Die neueren Images von Telekatz setzen einen (bestimmten!) Bootloader voraus.



ZitatDann habe ich noch den Einfach-Transceiver, der macht so alle zwei Sekunden eine neuen Satz /dev/ttyACM
Schnittstellen auf. Ich habe den LAN-Transceiver schon runtergenommen, aber es bleibt dabei  :(
Das hört sich so an als ob die eigentlich Software ständig neu startet. Wenn du einen Debug-Anschluss hast hier mal per USB-Wandler @115200 lauschen warum das der Fall ist.



*Wenn man einen USB Bootloader verwenden will muss auch HW-Seitig manches passen. (Pullups / Pulldown wegen USB disconnect um später das andere USB-Device zu sehen) Kann dir nicht sagen ob das mit dem Stick von Locutus klappt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 09 Juni 2017, 11:08:02
Ups,

da muss ich aber auch nochmal nachhaken
Zitat*Wenn man einen USB Bootloader verwenden will muss auch HW-Seitig manches passen. (Pullups / Pulldown wegen USB disconnect um später das andere USB-Device zu sehen)

Ich habe die 2 Fach Platine und gestern auch gesehen dass im Fhem Log der Maple immer nach dem Empfang einer 868 Nachricht disconnected und neu connected.
Ich hatte das jetzt erstmal auf mein nicht richtiges Wissen welcher meiner Chips 433 und welcher 868 ist und eventuell vertauschten Einstellungen geschoben und wollte das erstmal testen/nachschauen.

Brauche ich auch irgendwelche Pullups / Pulldowns mit Bootloader?

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 09 Juni 2017, 11:52:27
Der Stick von locutus sieht so aus, als ob er nicht die USB disconnect Schaltung vom Maple Mini hat. In dem Fall braucht man einen angepassten Bootloader, der die USB Verbindung anders trennen kann. Wie man den erstellt ist hier beschrieben:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader (https://github.com/rogerclarkmelbourne/STM32duino-bootloader)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 09 Juni 2017, 12:41:21
Ich habe diesen Bootloader hier für Locutus-Board  verwendet:

https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin)

Zusammen mit dieser Binary von hier:
https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507 (https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507)

Boot1 muss mit GND verbunden sein, ist die Lötbrücke auf der Unterseite der Platine, neben TX1 und RX1.
Beides mit FTDI-USB-Seriell-Wandler geflasht.
Diese Versionen  haben eine Abhängigkeit mit der Zuordnung der User-LED zum verwendeten I/O-Pin. 

Ohne USB, aber Arduino flasht über USB mit dfu-util:
Vorraussetzung: 3 Serielle COM-Schnittstellen und die erste ist als Arduino-Port angegeben.  Es sei dem, Windows enumeriert sie anders.
Bei mir war am Anfang die 2. Serielle die "Aktive", was sich leicht mit einem Terminal@115200Bd und dem Kommando "V" prüfen lasst....
Jede weitere MapleCUL-Platine enumeriert den COM-Port weiter nach oben.
Bei mir 18,19,20 die nächste Platine 20,21,22 etc. das ist auch noch ein störender Effekt.
Mal schauen, wie man das auf eine Schnittstellenserie festzurren kann... 



Habe diese Version seit 2 Wochen am BananaPi (noch zusammen mit 2 "normalen" NanoCULs) laufen.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 09 Juni 2017, 13:20:58
Hi, ich lösche im Gerätemanager immer die nicht verbundenen Geräte (muss man erst im Menu anzeigen) Dann werden die Ports wieder frei[emoji6]


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 10 Juni 2017, 03:04:21
Hi,

so hab jetzt soweit alles am Laufen auf der 2fach Platine. 433 und 868. Der 433 ist an cc0 and der 868 an cc1.
Soweit echt cool auf der Platine mit beiden Empfängern.
Ein Problem bleibt leider noch.

Immer wenn ich auf 868 von meinem ESA2000 (alle 3 min.) die Readings empfange disconnected und reconnected der Maple.
Der ESA ist mein einziges 868 Gerät. Lasse ich die 868 Antenne weg und empfange ich ihn nicht rebootet der Maple auch nicht.

Die Spannungsversorgung will ich eigentlich ausschließen. Habe das original Raspberry Netzteil mit 5.1V und 2,5A.
Habe den Maple nun auch noch über VCC und GND zusätzlich versorgt.
Das brachte alles keine besserung.

Im Log steht dann immer:
2017.06.10 02:55:07 1: /dev/serial/by-id/usb-STM32_MapleCUL_a55355d1-if00 disconnected, waiting to reappear (mapleCUL433_2)
2017.06.10 02:55:07 3: Setting mapleCUL433_2 serial parameters to 38400,8,N,1
2017.06.10 02:55:07 3: mapleCUL433_2: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2017.06.10 02:55:07 1: /dev/serial/by-id/usb-STM32_MapleCUL_a55355d1-if00 reappeared (mapleCUL433_2)
2017.06.10 02:55:07 3: mapleCUL868_2: Possible commands: bCFiAZNEGMKLUYRTVWXfz


Die readings wurden genau um 02:55:07 aktualisiert.
actual
0
2017-06-10 02:55:07
actual_ticks
0
2017-06-10 02:55:07
aktuell
0.00
2017-06-10 02:55:07
battery
ok
2017-06-10 02:55:07
day
1.33333333333333
2017-06-10 02:55:07
day_hr
2.49333333333333
2017-06-09 19:59:24
day_last
5.21333333333333
2017-06-10 00:00:53
day_lr
1.33333333333333
2017-06-10 02:55:07
diff
0.0000
2017-06-10 02:55:07
diff_sec
125
2017-06-10 02:55:07
diff_ticks
0
2017-06-10 02:55:07
hour
0.88
2017-06-10 02:55:07
hour_last
0.0533333333333333
2017-06-10 02:01:47
last_sec
1497056107
2017-06-10 02:55:07
letzteStunde
0.05
2017-06-10 02:55:07
letzterTag
5.21
2017-06-10 02:55:07
max
20.1
2017-05-06 11:26:23
month
51.4533333333341
2017-06-10 02:55:07
month_hr
14.9466666666669
2017-06-09 19:59:24
month_last
183.706666666642
2017-06-01 00:00:31
month_lr
36.5066666666665
2017-06-10 02:55:07
rate
LR
2017-06-10 02:55:07
raw
CNT: 126- CUM: 17637 CUR: 0 TICKS: 75 LR
2017-06-10 02:55:07
raw_total
216508.360
2017-06-10 02:55:07
repeat
-
2017-06-10 02:55:07
sequence
126
2017-06-10 02:55:07
state
CNT: 126- CUM: 235.160 CUR: 0.000 TICKS: 75 LR
2017-06-10 02:55:07
stunde
0.88
2017-06-10 02:55:07
tag
1.33
2017-06-10 02:55:07
ticks
75
2017-06-10 02:55:07
total
235.159999999948
2017-06-10 02:55:07
total_ticks
17637
2017-06-10 02:55:07
type
ESAx000WZ
2017-06-10 02:55:07
year
235.159999999948
2017-06-10 02:55:07
year_hr
63.5733333333361
2017-06-09 19:59:24
year_lr
171.586666666655
2017-06-10 02:55:07


Hat jemand da eine Idee was ich probieren könnte oder woran es liegen könnte?

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 10 Juni 2017, 11:29:06
Hallo Stefan,

scheint mir eher ein Hinweis auf ein Fehler in der FW.
Ich kenne das ESA gerät nicht. Deshalb kann ich zu dem Sachverhalt nicht weiter beitragen.

Wie bist Du zum Binary gekommen? aculfw selbst kompiliert ?

Hatte so einen ähnlichen Fall schon mal, wo ein Conditional nicht gegriffen hat und der
Funktionpointer ins Nirwana zeigte. Dann müsste man den Code und den Compiler Output dazu
genauer analysieren.

Kannst Du Einzelheiten zu den Einstellungen/Protokoll-Einstellung in aculfw dazu geben? Ein List des Devices wäre auch hilfreich....
Evtl ein verbose 5 und den output vor dem Reset ...

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 10 Juni 2017, 11:37:16
Hi Jürgen,

ich danke dir vielmals.
Ich denke es hat sich erledigt.
Seltsamerweise hat ein neustart von FHEM das Problem behoben.
Das verstehe ich nicht wirklich aber jetzt geht alles.

Ich muss hier nochmal allen Danken für die Hilfe.

Jetzt muss ich nur noch einen neuen mini USB Port Einlöten dann wäre das Projekt auch fertig :-)

Gruß und Danke,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 10 Juni 2017, 11:40:52
Hi Stefan,

reboot tut gut ...  :)
Du weißt aber nicht, ob sich der Zustand möglicherweise irgendwann wieder einstellt....

Aber da täte sich die Frage auf:
Die MapleCUL-FW-Variante emuliert ja das ATmega-EEPROM im Flash.
Wäre da ein "set <mapleCUL> raw e" hilfreich gewesen?

Wobei das Eine mit dem Anderen nichts zu tun hat.


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 11 Juni 2017, 14:55:23
Zitat von: PeMue am 09 Juni 2017, 07:32:15
Hallo zusammen,

ich habe den einfach Transceiver von locutus an meinen Raspberry Pi angeschlossen (ohne Netzwerk Transceiver) und bekomme regelmäßig folgende Meldung mit

tail -f /var/log/syslog

Jun  9 07:24:22 PMRPI03 kernel: [3952458.309772] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:22 PMRPI03 kernel: [3952458.309789] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:22 PMRPI03 kernel: [3952458.309805] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:22 PMRPI03 kernel: [3952458.311543] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:22 PMRPI03 kernel: [3952458.314917] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:22 PMRPI03 kernel: [3952458.317668] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:24 PMRPI03 kernel: [3952460.262660] usb 1-1.5: USB disconnect, device number 111
Jun  9 07:24:24 PMRPI03 kernel: [3952460.501911] usb 1-1.5: new full-speed USB device number 112 using dwc_otg
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609647] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609677] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609707] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609725] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:24 PMRPI03 kernel: [3952460.609741] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:24 PMRPI03 kernel: [3952460.611459] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:24 PMRPI03 kernel: [3952460.615007] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:24 PMRPI03 kernel: [3952460.617504] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:26 PMRPI03 kernel: [3952462.310928] usb 1-1.5: USB disconnect, device number 112
Jun  9 07:24:26 PMRPI03 kernel: [3952462.551922] usb 1-1.5: new full-speed USB device number 113 using dwc_otg
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659795] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659824] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659866] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659884] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:26 PMRPI03 kernel: [3952462.659900] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:26 PMRPI03 kernel: [3952462.661541] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:26 PMRPI03 kernel: [3952462.664032] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:26 PMRPI03 kernel: [3952462.666544] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:28 PMRPI03 kernel: [3952464.615266] usb 1-1.5: USB disconnect, device number 113
Jun  9 07:24:29 PMRPI03 kernel: [3952464.851925] usb 1-1.5: new full-speed USB device number 114 using dwc_otg
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959722] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959751] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959800] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959817] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:29 PMRPI03 kernel: [3952464.959833] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:29 PMRPI03 kernel: [3952464.962104] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:29 PMRPI03 kernel: [3952464.964632] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:29 PMRPI03 kernel: [3952464.967124] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:31 PMRPI03 kernel: [3952466.919540] usb 1-1.5: USB disconnect, device number 114
Jun  9 07:24:31 PMRPI03 kernel: [3952467.161906] usb 1-1.5: new full-speed USB device number 115 using dwc_otg
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269655] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269684] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269721] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269739] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:31 PMRPI03 kernel: [3952467.269755] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:31 PMRPI03 kernel: [3952467.273869] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:31 PMRPI03 kernel: [3952467.276930] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:31 PMRPI03 kernel: [3952467.280472] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:33 PMRPI03 kernel: [3952468.967826] usb 1-1.5: USB disconnect, device number 115
Jun  9 07:24:33 PMRPI03 kernel: [3952469.281934] usb 1-1.5: new full-speed USB device number 116 using dwc_otg
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389558] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389588] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389620] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389637] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:33 PMRPI03 kernel: [3952469.389653] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:33 PMRPI03 kernel: [3952469.391420] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:33 PMRPI03 kernel: [3952469.394933] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:33 PMRPI03 kernel: [3952469.398043] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:35 PMRPI03 kernel: [3952471.272137] usb 1-1.5: USB disconnect, device number 116
Jun  9 07:24:35 PMRPI03 kernel: [3952471.511971] usb 1-1.5: new full-speed USB device number 117 using dwc_otg
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619865] usb 1-1.5: New USB device found, idVendor=0483, idProduct=5743
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619895] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619925] usb 1-1.5: Product: MapleCUL
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619942] usb 1-1.5: Manufacturer: STM32
Jun  9 07:24:35 PMRPI03 kernel: [3952471.619958] usb 1-1.5: SerialNumber: e07896cf
Jun  9 07:24:35 PMRPI03 kernel: [3952471.621737] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
Jun  9 07:24:35 PMRPI03 kernel: [3952471.624934] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
Jun  9 07:24:35 PMRPI03 kernel: [3952471.627597] cdc_acm 1-1.5:1.4: ttyACM2: USB ACM device
Jun  9 07:24:37 PMRPI03 kernel: [3952473.576465] usb 1-1.5: USB disconnect, device number 117

Ist da die falsche Firmware drauf?

Nicht die falsche, sondern die veraltete, Bootloader freie Firmware aus der Entwicklungszeit. Damals waren unterschiedliche Firmwarevarianten für Maple Mini mit und ohne Netzwerkcontroller erforderlich.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 11 Juni 2017, 17:10:19
Zitat von: locutus am 11 Juni 2017, 14:55:23
Nicht die falsche, sondern die veraltete, Bootloader freie Firmware aus der Entwicklungszeit. Damals waren unterschiedliche Firmwarevarianten für Maple Mini mit und ohne Netzwerkcontroller erforderlich.
Sprich ich habe jetzt zwei Möglichkeiten:
- den Bootloader per serieller Schnittstelle flashen und dann die Binary von Mediafire per USB zu flashen oder
- neu zu compilieren (wie beim mapleCUL USB Stick) und die Firmware per serieller Schnittstelle zu flashen, oder?

Danke + Gruß

Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 11 Juni 2017, 17:54:03
Hallo locutus + Peter,

ich habe jetzt 5 MapleCULs aus locutus DualTransceiver-Platine aufgebaut.
Davon funktionieren 4 sehr zuverlässig und eine zeigt ein ähnliches Verhalten wie die von PeMue.

Bei allen ist die gleiche Variante seriell geflasht worden:

Zuerst Bootloader von hier:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin)

Dann Applikationsbinary MapleCULx4.bin von hier:
https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507 (https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507)

Eine Platine zeigt ein ähnliches Verhalten mit den Disconnects, wie die von PeMue (allerdings unter Windows).
Ich wollte das heute reproduzieren bzw. untersuchen. Leider funktioniert das heute tadellos ... :o

Deshalb:
Zitat von: locutus am 11 Juni 2017, 14:55:23
Nicht die falsche, sondern die veraltete, Bootloader freie Firmware aus der Entwicklungszeit. Damals waren unterschiedliche Firmwarevarianten für Maple Mini mit und ohne Netzwerkcontroller erforderlich.
auf was für eine Bootloader-Variante/Version beziehst Du Dich da genau?

Grüße,
Jürgen 

PS: Auch der maple_mini_boot20.bin-Bootloader funktioniert:
maple-mini-clone-bootloader-flashen (https://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/)
bzw. dieser hier:
stm32f103-minimal-board-bootloader-flashen (https://born2bastel.de/2017/02/08/stm32f103-minimal-board-bootloader-flashen/)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 11 Juni 2017, 19:05:52
Zitat von: PeMue am 11 Juni 2017, 17:10:19
Sprich ich habe jetzt zwei Möglichkeiten:
- den Bootloader per serieller Schnittstelle flashen und dann die Binary von Mediafire per USB zu flashen oder
- neu zu compilieren (wie beim mapleCUL USB Stick) und die Firmware per serieller Schnittstelle zu flashen, oder?
Du hast den üblichen STM32 Maple Mini vom Chinamann? Du kannst die Optionen anwenden, die hier besprochen und zur Verfügung gestellt worden sind.
Aus dem Thema Bootloader bin ich raus. Ich habe mich nie damit auseinandergesetzt, nur hier mitgelesen.

Zitat von: juergs am 11 Juni 2017, 17:54:03
Deshalb:auf was für eine Bootloader-Variante/Version beziehst Du Dich da genau?
Version 1.23.xx (https://github.com/heliflieger/a-culfw/blob/master/CHANGELOG) ohne Bootloader!

Das makefile ist in der Lage, folgende Targets zu erzeugen:
MapleCUL
MapleCUN
MapleCULx4
MapleCUNx4
MapleCUNx4_W5100
MapleCUNx4_W5500
MapleCUNx4_W5100_BL
MapleCUNx4_W5500_BL

Nur zwei davon unterstützen offiziell den Bootloader. Dazu hat sich der Maintainer bereits in Antwort #326 (https://forum.fhem.de/index.php/topic,60458.msg645236.html#msg645236) geäußert.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 11 Juni 2017, 19:12:47
Hi PeMue,
bin ich bis jetzt der einzige hier, der den Bootloader hiermit über USB geändert hat?

https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 12 Juni 2017, 14:13:35
Hallo zusammen,

dieser
Zitat von: juergs am 09 Juni 2017, 12:41:21
Ich habe diesen Bootloader hier für Locutus-Board  verwendet:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin)

bzw. dieser
Zitat von: juergs am 11 Juni 2017, 17:54:03
Zuerst Bootloader von hier:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin)

bzw. dieser hier
Zitat von: juergs am 11 Juni 2017, 17:54:03
... bzw. dieser hier:
stm32f103-minimal-board-bootloader-flashen (https://born2bastel.de/2017/02/08/stm32f103-minimal-board-bootloader-flashen/)
zeigt immer auf denselben Bootloader.

Daher haben wir nur zwei Varianten.
- den von Telekatz (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/STM32F1/binaries/maple_mini_boot20.bin) = maple_mini_boot20.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/STM32F1/binaries/maple_mini_boot20.bin)
bzw. den
- generic_boot20_pc13.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin)

Zur Sicherheit werde ich die maple Mini Schaltung mit auf die Leiterplatte machen.

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 12 Juni 2017, 19:43:15
Hallo Peter,

q.e.d.  ;)

Jürgen

PS:
https://www.youtube.com/watch?v=J7ctdFaBZ20 (https://www.youtube.com/watch?v=J7ctdFaBZ20)
ab ca. 15 min ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 15 Juni 2017, 08:04:25
Hallo zusammen,

ich schaffe es irgendwie nicht, den Bootloader zu brennen:
- USB2seriell Wandler ist angeschlossen (Rx<->Tx, Tx<->Rx, GND verbunden), die Kreuzung habe ich dreimal geprüft
- ich habe auf dem Raspberry Pi stm32flash heruntergeladen und compiliert
- USB2seriell an USB Anschluss des Raspberries (mappt auf /dev/ttyUSB2), Spannung an den maple Mini
- but 32 gedrückt + gehalten, reset gedrückt, beide Tasten losgelassen, die blinkende blaue LED hört auf zu blinken
stm32flash /dev/ttyUSB2 sagt

stm32flash 0.5
http://stm32flash.sourceforge.net/
Interface serial_posix: 57600 8E1
Failed to init device.

Dasselbe mit einem anderen maple Mini bzw. auch mit BOOT1 auf GND gezogen. Irgendwo ist noch
ein prinzipieller Fehler, den ich aber gerade nicht sehe  :-\

Nebenbei: Wenn ich den Bootloader draufbrenne, und den USB2Seriell Adapter angeschlossen habe, könnte ich ja auf gleiche Weise die MapleCUNx4_W5100_BL.bin draufbrennen, oder? Oder muss die zwingend per USB geflasht werden?

Danke für Eure Hinweise.

Ich werde mich erstmal wieder um etwas anderes kümmern  :(

Übrigens: Mein 2-fach mapleCUL von locutus funktioniert, aber irgendwie klappt das mit den Treibern unter Windows nicht, da nehme ich doch lieber eine (kleine) Linux Maschine.

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: papa am 15 Juni 2017, 08:21:38
Ich habe mir für den STM32 nen ST-Link Nachbau (https://de.aliexpress.com/item/Hot-Sale-1PCS-ST-LINK-Stlink-ST-Link-V2-Mini-STM8-STM32-Simulator-Download-Programmer-Programming/32343514985.html) angeschafft. Damit geht das flashen über die Debug-Schnittstelle ganz einfach.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 15 Juni 2017, 08:39:54
Zitat von: papa am 15 Juni 2017, 08:21:38
Ich habe mir für den STM32 nen ST-Link Nachbau (https://de.aliexpress.com/item/FREE-SHIPPING-1PCS-ST-Link-V2-stlink-mini-STM8STM32-STLINK-simulator-download-programming-With-Cover/32329418477.htm) angeschafft. Damit geht das flashen über die Debug-Schnittstelle ganz einfach.

Link funktioniert nicht...

vermutlich meinst die diesen hier:

http://www.ebay.de/itm/ST-Link-V2-Mini-STM8-STM32-STLINK-Simulator-Download-Programming-with-Cover-/222225024871?hash=item33bda4c767:g:~sYAAOSw65FXuHpe



Viele Grüße!

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: papa am 15 Juni 2017, 09:05:04
Ja danke. Link oben auch gefixed.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Juni 2017, 09:50:41
@Peter: Ich flashe den Bootloader anders.


Den außeren Button halten (Bot), Spannung anlegen über USB, Button loslassen und sehr schnell den Flashbefehl eingeben.
Damit ich ich nicht schnell sein muss hab ich ein winziges Script welches in einer Schleife läuft und ständig jede Sekunde den Flash Befehl abschickt.

-Und natürlich muss das Flashprogramm auch Zugriffrechte auch das Device haben:/dev/ttyUSB2, also am besten per sudo oder als user root aufrufen!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 15 Juni 2017, 09:56:41
Hallo Peter,

Zitatstm32flash 0.5
http://stm32flash.sourceforge.net/
Interface serial_posix: 57600 8E1
Failed to init device.

Hast Du mit einem Kurzschluss zwischen RX-TX mit z.B. Miniterm probiert, ob dieser Teil der Strecke funktioniert?

Ich nehme an dass Du auf Dein neues Board Bezug nimmst...


Zu den Standard Boards gibt es noch einige Anmerkungen:
http://wiki.stm32duino.com/index.php?title=Blue_Pill (http://wiki.stm32duino.com/index.php?title=Blue_Pill)
Zur Falsch-Bestückung des USB-Ports:
http://wiki.stm32duino.com/images/c/c1/Vcc-gnd.com-STM32F103C8-schematic.pdf (http://wiki.stm32duino.com/images/c/c1/Vcc-gnd.com-STM32F103C8-schematic.pdf)

Dann zum libusb - Device im Bootloader-Modus unter Windows (Treiber):
http://wiki.stm32duino.com/index.php?title=Windows_driver_installation (http://wiki.stm32duino.com/index.php?title=Windows_driver_installation)

Evtl. ist die libusb zum Beispiel mit Zadig.exe zu setzen.
(Mit Vorsicht zu geniessen, evtl. macht man sich eine andere USB-Installation damit kaputt..)

Ich benutze lieber diese Form unter Windows hier: http://libusb.info/ (http://libusb.info/) oder hier die Binaries
https://sourceforge.net/projects/libusb-win32/postdownload?source=dlp (https://sourceforge.net/projects/libusb-win32/postdownload?source=dlp)
mit der inf-wzard.exe und install-filter.exe und den passenden Testprogrammen dazu.

Die Rahmenbedingungen für Serial-Upload:

ZitatAllow firmware upload through USART1:
    Boot0 HIGH
    Boot1 LOW

Diese Variante werde ich noch bei mir ausprobieren:
http://www.stm32duino.com/viewtopic.php?t=122 (http://www.stm32duino.com/viewtopic.php?t=122)

Falls Du noch Hardware-Tester brauchst ...  ;)

@Ranseyer:
Eigentlich heißt diese Bootloader-Flash-Form ja "perpetual bootloader mode". Das Verhalten das Du beschreibst scheint mir etwas Raspi-spezifisches zu sein,
um doch noch Flashen zu können !?

Grüße,
Jürgen


PS: Verdrücke mich jetzt an den Baggersee, bevor die "Schwaben" einfallen   ;D ;D ;D
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Juni 2017, 10:12:03
ZitatPerpetual bootloader mode". Das Verhalten das Du beschreibst scheint mir etwas Raspi-spezifisches zu sein,
um doch noch Flashen zu können !?

Keine Ahnung wie das heisst. Ich Flashe jedenfalls von meinem Desktop-PC (mit Linux) Betriebssystem.
Von Windows halte ich in dem Fall wenig, denn hier braucht man zusätzlich auch noch Treiber. Also eine zusätzliche Fehlerquelle, wovon es ja schon genügend gibt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 15 Juni 2017, 10:25:26
ZitatVon Windows halte ich in dem Fall wenig, denn hier braucht man zusätzlich auch noch Treiber. Also eine zusätzliche Fehlerquelle, wovon es ja schon genügend gibt.

Na ja stimmt so nicht: libusb brauchst auch unter Linux, oder ....

Zumm Flashen alleine brauchst Du keinen Treiben, nur den für den USB2Serial ...

Damit nach dem Flashen die 3 Seriellen Schnittstellen des Maple "aufgehen" brauchst Du wohl die libusb ....

Jürgen

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Juni 2017, 12:01:40
LibUSB brauche ich meist nur in Form des LibUSB-Dev Paketes. Das wird somit fest einkompiliert. In diesem Fall gebe ich h zu habe ich nicht mehr m Kopf was ich dazu genau vor 1-2 Jahren getan habe. Fakt dürfte trotzdem sein dass man unter Linux direkten Zugriff auf die HW hat und somit ein besseres Gefühl dafür entwickeln kann. Möglicherweise kommt mein aktueller Windows Frust auch mehr vom Flashen von ein paar Xiaomi Handys unter Windows. (Auch hier wieder ein Treiber Thema)
Sorry für OT. Natürlich sollte jeder das OS verwenden von dem er Ahnung hat. (Aber für Windows gibt es von mir dann kaum Support. Davon habe ich langsam immer weniger Ahnung, und das ist gut so)

Gesendet von meinem HTC One_M8 mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 15 Juni 2017, 14:27:53
Hallo Ranseyer,

danke für die ehrliche Antwort, die ich gerne mit Dir teile.

Das artet aber immer im Allgemeinen in die "Was-ist-das-bessere-OS-Diskussion" aus ...
Aber die IT obliegt immer mehr dem Wandel, in eine rasante Geschwindigkeit, die es einem wirklich schwer macht,
immer am "Ball" zu bleiben. 

Wenn man sich nicht mehr darauf einlassen will hat man praktisch schon "verloren".
Deshalb wieder zurück zum Thema....  ;) :) sonst schwingt wieder einer die große "Off-Topic"-Keule ...  ;D

ZitatWindows Frust auch mehr vom Flashen von ein paar Xiaomi Handys unter Windows.
Das liegt dann aber eher am Hersteller, der bei der Erstellung des Treibers sparen wollte ...  :(

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 17 Juni 2017, 08:39:46
Hallo,

Zitat von: juergs am 15 Juni 2017, 09:56:41
Hast Du mit einem Kurzschluss zwischen RX-TX mit z.B. Miniterm probiert, ob dieser Teil der Strecke funktioniert?
ja, habe ich. Zwar nicht mit minicom, aber mit sudo cat /dev/ttyUSB2, nachdem ich vorher die serielle Schnittstelle per stty eingestellt habe. Der USB2seriell Adapter funktioniert, auch am Raspberry Pi.

Zitat von: juergs am 15 Juni 2017, 09:56:41
Ich nehme an dass Du auf Dein neues Board Bezug nimmst ...
Nein, erstmal möchte ich mit einem neuen maple Mini (bzw. dem, der auf locutus' Board drauf ist) Erfahrungen sammeln.

Zitat von: Ranseyer am 15 Juni 2017, 09:50:41
Ich flashe den Bootloader anders.
Den außeren Button halten (Bot), Spannung anlegen über USB, Button loslassen und sehr schnell den Flashbefehl eingeben.
Kommt im Prinzip auf dasselbe raus, aber tut leider bei mir am Raspberry Pi auch nicht.

Zitat von: Ranseyer am 15 Juni 2017, 09:50:41
Damit ich ich nicht schnell sein muss hab ich ein winziges Script welches in einer Schleife läuft und ständig jede Sekunde den Flash Befehl abschickt.
Könntest Du bitte noch mal einen Link auf Deine Skripte posten, ich habe nur eins gefunden, aber das braucht den geflashten Bootloader ...

Wie ist denn die Einstellung der Baudrate beim Loggen der mapleCUx Firmware? Es kommt etwas an, aber ich bekomme nur komische Zeichen (Baudraten von 9600 bis 115200)?

Das mit den Windows Treibern klappt auch nicht, ich musste zadig_3.2.exe verwenden (Windows 7). Mittlerweile werden zwei von den drei Schnittstellen installiert (ich weiß aber nicht mehr, welcher USB Treiber das war) und ich kann mit einem Terminalprogramm auf locutus' mapleCUl (2-fach) zugreifen und die Version auslesen.

Alles in allem widersetzt sich mir das Board noch erheblich  :P

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 17 Juni 2017, 10:02:33
@Peter: schaust Du hier: https://forum.fhem.de/index.php/topic,60458.msg645326.html#msg645326
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 17 Juni 2017, 12:50:40
Hallo PeMue,

ZitatDas mit den Windows Treibern klappt auch nicht, ich musste zadig_3.2.exe verwenden (Windows 7). Mittlerweile werden zwei von den drei Schnittstellen installiert (ich weiß aber nicht mehr, welcher USB Treiber das war) und ich kann mit einem Terminalprogramm auf locutus' mapleCUl (2-fach) zugreifen und die Version auslesen.
Alles in allem widersetzt sich mir das Board noch erheblich 

... da ich gerade Windows 10 neu installiere, kann ich das mal dokumentieren, wie/ob ich es (wieder) zum Laufen bekomme....
Mit der gesamten Toolchain neu ... Backup-Faulheit sei Dank....  :(

Zitat.... habe ich nicht mehr im Kopf was ich dazu genau vor 1-2 Jahren getan habe  ...
Anmerkung: damit es funktioniert ... so geht es mir gerade auch ...  ;)

ZitatMittlerweile werden zwei von den drei Schnittstellen installiert
Seltsam. Wenn man die "reagierende " Serielle ansprechen kann , ist das schon mal die halbe Miete.

Welche Binary hast Du eingesetzt?

Grüße,
Jürgen


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 17 Juni 2017, 16:10:19
Zitat von: juergs am 17 Juni 2017, 12:50:40
... da ich gerade Windows 10 neu installiere, kann ich das mal dokumentieren, wie/ob ich es (wieder) zum Laufen bekomme....
Mit der gesamten Toolchain neu ... Backup-Faulheit sei Dank....  :(
Probier dann mal, die Treiber wie hier (https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation) beschrieben zu installiern.
Das dfu-util ist in diesem Paket auch schon enthalten. Auf einem Windows 10 Rechner ohne DFU Treiber hat das bei mir funktioniert.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 17 Juni 2017, 18:04:06
Hallo Telekatz,

super + danke!

War sehr hilfreich, anbei die Outputs (Win10 Pro X64).
Vorsorglich habe ich die beiden BAT-Dateien "als Administrator" ausgeführt.

Also: Ein "richtiger"  Maple nur mit Bootloader, dann ein mit der aculfw-geflashter Locutus-Stick mit den 3 Schnittstellen ...
Interessanterweise ist nicht immer die niedrigste auch die reagierende Schnittstelle.

Hilfreich, wenn man oft mit Seriellen arbeitet:
serial-port-monitor im Tray (http://helmpcb.com/software/serial-port-monitor)

Dann probiere ich noch den Bootloader-only Maple unter arduino 1-6-7 mit dem Blink-Sample zu programmieren ...
Das sollte es gewesen sein.  :)

Anm.: Das verbliebene "Unbekannte Gerät"  ist der Fingerabdrucksensor der nicht installiert ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 17 Juni 2017, 20:06:48
Mit meiner Arduino-Version bekomme ich Probleme beim Compile (Ok, die Version ist zugegebener Maßen etwas alt!) :

ZitatArduino: 1.6.7 (Windows 10), Board: "Maple Mini, Original (17k RAM,108k Flash), 72Mhz (Normal)"

D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\arduino-builder -dump-prefs -logger=machine -hardware "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\hardware" -hardware "C:\Users\Jürgen\AppData\Local\Arduino15\packages" -hardware "C:\Users\Jürgen\Documents\Arduino\hardware" -tools "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\tools-builder" -tools "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\hardware\tools\avr" -tools "C:\Users\Jürgen\AppData\Local\Arduino15\packages" -built-in-libraries "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\libraries" -libraries "C:\Users\Jürgen\Documents\Arduino\libraries" -fqbn=Arduino_STM32:STM32F1:mapleMini:bootloader_version=original,cpu_speed=speed_72mhz -ide-version=10607 -build-path "C:\Users\JRGEN~1\AppData\Local\Temp\buildbd628dfaa6522d6024ce8d98d1c8479c.tmp" -warnings=none -prefs=build.warn_data_percentage=75 -verbose "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\examples\01.Basics\Blink\Blink.ino"
D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\arduino-builder -compile -logger=machine -hardware "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\hardware" -hardware "C:\Users\Jürgen\AppData\Local\Arduino15\packages" -hardware "C:\Users\Jürgen\Documents\Arduino\hardware" -tools "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\tools-builder" -tools "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\hardware\tools\avr" -tools "C:\Users\Jürgen\AppData\Local\Arduino15\packages" -built-in-libraries "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\libraries" -libraries "C:\Users\Jürgen\Documents\Arduino\libraries" -fqbn=Arduino_STM32:STM32F1:mapleMini:bootloader_version=original,cpu_speed=speed_72mhz -ide-version=10607 -build-path "C:\Users\JRGEN~1\AppData\Local\Temp\buildbd628dfaa6522d6024ce8d98d1c8479c.tmp" -warnings=none -prefs=build.warn_data_percentage=75 -verbose "D:\Program Files (x86)\Arduino\arduino-1.6.7-windows\arduino-1.6.7\examples\01.Basics\Blink\Blink.ino"
"C:\Users\Jürgen\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++"  -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11  -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple_mini -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -DF_CPU=72000000L -DARDUINO=10607 -DARDUINO_MAPLE_MINI -DARDUINO_ARCH_STM32F1   -DMCU_STM32F103CB -DSERIAL_USB  -mthumb  -march=armv7-m -D__STM32F1__       "-IC:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple" "-IC:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\maple_mini" "C:\Users\JRGEN~1\AppData\Local\Temp\buildbd628dfaa6522d6024ce8d98d1c8479c.tmp\sketch\Blink.ino.cpp" -o "nul"
"C:\Users\Jürgen\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++"  -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11  -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_maple_mini -DVECT_TAB_ADDR=0x8005000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -DF_CPU=72000000L -DARDUINO=10607 -DARDUINO_MAPLE_MINI -DARDUINO_ARCH_STM32F1   -DMCU_STM32F103CB -DSERIAL_USB  -mthumb  -march=armv7-m -D__STM32F1__       "-IC:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple" "-IC:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\maple_mini" "C:\Users\JRGEN~1\AppData\Local\Temp\buildbd628dfaa6522d6024ce8d98d1c8479c.tmp\sketch\Blink.ino.cpp" -o "C:\Users\JRGEN~1\AppData\Local\Temp\buildbd628dfaa6522d6024ce8d98d1c8479c.tmp\preproc\ctags_target_for_gcc_minus_e.cpp"
In file included from C:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple/wirish.h:52:0,

                 from C:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple/Arduino.h:30,

                 from C:\Users\JRGEN~1\AppData\Local\Temp\buildbd628dfaa6522d6024ce8d98d1c8479c.tmp\sketch\Blink.ino.cpp:1:

C:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple/libmaple/stm32.h:85:2: error: #error "Bad STM32F1 configuration. Check <series/stm32.h> header for your MCU."

#error "Bad STM32F1 configuration. Check <series/stm32.h> header for your MCU."

  ^

In file included from C:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple/wirish.h:54:0,

                 from C:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple/Arduino.h:30,

                 from C:\Users\JRGEN~1\AppData\Local\Temp\buildbd628dfaa6522d6024ce8d98d1c8479c.tmp\sketch\Blink.ino.cpp:1:

C:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple/boards.h:37:37: fatal error: libmaple/libmaple_types.h: No such file or directory

#include <libmaple/libmaple_types.h>

                                     ^

compilation terminated.

exit status 1
Error compiling.

OK, versuche mal eine neuere Version. (Das Nachliefern der STM32.h in "..STM32F1\cores\maple/libmaple/stm32.h" war keine gute Idee!)

Eine Installation einer neueren Toolchain (/edit: unnötig Arduino bringt sie schon mit):
https://launchpad.net/gcc-arm-embedded
hat nichts genützt, ist im Pfad als erster Eintrag vorhanden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 17 Juni 2017, 21:19:16
Zitat... Linking everything together...
"C:\Users\Jürgen\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++" -Os -Wl,--gc-sections -mcpu=cortex-m3 "-TC:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\maple_mini/ld/flash.ld" "-Wl,-Map,C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045/Blink.ino.map" "-LC:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\maple_mini/ld" -o "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045/Blink.ino.elf" "-LC:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045" -lm -lgcc -mthumb -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045\sketch\Blink.ino.cpp.o" "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045\core\wirish\start.S.o" "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045\core\wirish\start_c.c.o" "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045\core\wirish\syscalls.c.o" "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045\core\board.cpp.o" "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045\core\wirish\boards.cpp.o" "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045\core\wirish\boards_setup.cpp.o" "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045/core\core.a" -Wl,--end-group
"C:\Users\Jürgen\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-objcopy" -O binary  "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045/Blink.ino.elf" "C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045/Blink.ino.bin"
Sketch uses 12924 bytes (11%) of program storage space. Maximum is 110592 bytes.
Global variables use 2816 bytes of dynamic memory.
C:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM14 1 1EAF:0003 C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045/Blink.ino.bin
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...

Found it!

Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=258
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode


OK. Eine uralte 1.5.3 Version stellte sich quer und wollte sich nicht deinstalieren lassen.
Dateien manuell gelöscht und mit CCleaner den Eintrag der 1.5.3er gelöscht.

Dann ließ sich sich die aktuelle 1.8.3 installieren und:
der Compile geht durch und lässt sich auf den Maple (installiert ein Port COM9) flashen... 

Alles gut  :)

Ein COM14 war zur Zeit des Uploads noch nicht da , ist wohl dummy, da dfu (COM-Port Einstellung ist ausgegraut):
C:\Users\Jürgen\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM14 1 1EAF:0003 C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_356045/Blink.ino.bin

Beim "Orginal" Maple?
ZitatResetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...

Die Version "Arduino: 1.6.7"  scheint definitv zu alt ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 19 Juni 2017, 22:16:59
So, I did it!

Kurzversion:
- Einer der maple Mini scheint einen Hardwaredefekt zu haben (der von locutus' LAN Variante), warum auch immer.
  Ggf. habe ich die Hardware "geschrottet" indem ich den maple Mini einmal falschherum eingebaut habe?
  Falls sich jemand berufen fühlt, das Teil noch mal retten zu wollen, schicke ich ihm den maple Mini gerne zu  ;)


- Mit dem STM Flash Loader konnte ich auf den anderen den Bootloader brennen und mit Hilfe von dfu-util die Firmware flashen

Frage:
- Ist es normal, dass dfu-util nur bis 96 % geht? Die Firmware scheint aber zu funktionieren ...

Details mit Bildern gibt es demnächst ...

Gruß PeMue

Edit1: Ich habe heute morgen Ranseyer's Kommentar befolgt und nur das maple Mini Board genommen und siehe da: es funktioniert. Jetzt probiere ich das noch am Raspberry Pi, die Bilderserie folgt ...

Edit2: Bei locutus' 1-fach Platine muss Tx mit Tx und Rx mit Rx verbunden werden (nicht kreuzen), dann ist auch eine serielle Kommunikation möglich.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 19 Juni 2017, 22:31:36
Hi,
Zitat von: PeMue am 19 Juni 2017, 22:16:59
Frage:
- Ist es normal, dass dfu-util nur bis 96 % geht? Die Firmware scheint aber zu funktionieren ...
"normal" wohl nicht, aber "üblich"... ,-)
Nee, ist bei mir auch IMMER der Fall und ich hab meinen gefühlt schon 200 Mal geflasht. Funktioniert aber immer. Habe mir nicht die Mühe gemacht da mal im Code nachzusehen woran das liegt, habe genügend in der Firmware zu debuggen das ich nicht auch noch den Brenner debuggen will...

Gruß,
Andreas.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 26 Juni 2017, 08:26:00
Hi,
kann mir jemand sagen, warum mein MapleCUL folgende Meldung schreibt:
2017.06.26 02:38:16 5: CUL/RAW: /*i11115471
*i11115471
2017.06.26 02:38:16 4: CUL_Parse: CULMAPLE868 *i11115471
2017.06.26 02:38:16 5: CULMAPLE868: dispatch *i11115471
2017.06.26 02:38:16 1: CULMAPLE433: no client device assigned
2017.06.26 02:38:17 4: CUL_Parse: CULMAPLE868 *i11115471
2017.06.26 02:38:17 5: CULMAPLE868: dispatch *i11115471
2017.06.26 02:38:17 1: CULMAPLE433: no client device assigned


Das passiert wenn ich auf einer Intertechno V1 Handfernbedienung drücke.

Der 868 hat in FHEM als STACKABLE_CC den 433 "drauf".

Gruß Arnd
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 27 Juni 2017, 16:45:05
Hi,
ich brauche Eure Nachhilfe. Wenn ich den zweifach MAPLE von locutus wie folgt definiere:


define MAPLE CUL COM9@38400 2143
attr MAPLE icon cul_868
attr MAPLE model CUN
attr MAPLE room Hardware
attr MAPLE verbose 5

define MAPLE2 STACKABLE_CC MAPLE
attr MAPLE2 icon cul_cul
attr MAPLE2 room Arbeitszimmer,Hardware

dann funktioniert ccconf und version auf beiden MAPLE und MAPLE2.

Aber alle Versuche über STACKABLE anstatt STACKABLE_CC gehen bei mir nicht.
Brauche ich besondere FHEM Modul Versionen?

Ja dies ist jetzt das Windows Testsystem, aber auf dem Pi bekomme ich es auch nicht hin!

Any thoughts?

Gruß Arnd
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 27 Juni 2017, 16:58:37
Hi,

wie sieht denn Deine Definition für STACKABLE aus?
Da muss man ja eine Art "Zwischendevice" definieren und man kann eben nicht einfach das "_CC" aus der Defintion entfernen und gut ist...

Ich habe allerdings "nur" eine 4x ZWave Variante laufen und nutze weder cconf noch eine explizite Version Abfrage, bin mir aber recht sicher das dies bei der Initialisierung gemacht wird und auch funktioniert.

Bin gerade nicht zu Hause und komme von extern nicht an mein Entwicklungssytem, daher kann ich Dir jetzt gerade nicht sagen wie ich das genau definiert habe. Es gibt bei mir aber SCC1, SCC2 und SCC3 definitionen die quasi die Zwischenschichten darstellend und dann die eigentlichen ZWave-Definitionen die auf diese Zwischenschichten verweisen. Ich bin mir aber aus dem Kopf leider nicht mehr sicher ob z.B. SCC2 jetzt auf SCC1 aufbaut oder auf dem ZWave-Device welches auf SCC1 verweist.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 18:13:22
Hallo Arnd,
es funktioniert nur mit "STACKABLE_CC"!

Grüße,
Jürgen

attr MAPLE model CUN
???
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 27 Juni 2017, 18:33:03
Zumindest unter Linux funktioniert es auch mit STACKABLE. Man muss aber vorher alle STACKABLE_CC löschen.

define CUL_0 CUL /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@42 1235

define CUL_0_SCC STACKABLE CUL_0
define CUL_1 CUL FHEM:DEVIO:CUL_0_SCC:42 2345

define CUL_1_SCC STACKABLE CUL_1
define CUL_2 CUL FHEM:DEVIO:CUL_1_SCC:42 3412


Unter Windows habe ich es allerdings auch noch nicht zum laufen gebracht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 18:59:27
..bei mir geht es unter beiden BS 😀
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 27 Juni 2017, 19:06:46
Mit STACKABLE oder mit STACKABLE_CC?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 19:12:50
STACKABLE_CC.

Ich prüfe unter Win10 welche COM-Schnittstelle auf "V" reagiert.
Bitrate ist egal, 38 und 115 gehen...
Ist bei mir nicht immer die erste der 3 Schnittstellen,aber meist...
Diese übernehme ich in die erste Maple Definition.
Grüße,
Jūrgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 27 Juni 2017, 19:20:20
Mit STACKABLE_CC geht es bei mir auch unter Windows. Die Frage war aber, wie es mit STACKABLE funktioniert.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 19:24:28
Ok, Gegenfrage: Was ist der Unterschied?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 27 Juni 2017, 19:33:46
STACKABLE soll STACKABLE_CC ersetzen: https://forum.fhem.de/index.php/topic,68811.msg603790.html#msg603790 (https://forum.fhem.de/index.php/topic,68811.msg603790.html#msg603790)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 19:44:08
Danke, kannte den Thread nicht.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 27 Juni 2017, 20:50:46
Hi, schon einmal Danke!

Bei mir gehen die Definitionen mit
CUL1 -> CUL1_STACK -> CUL2 auch,
Aber CUL2 bleibt immer auf opened.

Was genau bedeutet alle STACKABLE_CC müssen gelöscht sein?
Ich weiss, dass schon jemand geschrieben hatte, dass die nicht parallel gingen. Aber was genau habt ihr gemacht?
STACKABLE_CC Geräte gelöscht
CUL1_STACK und CUL2 definiert
shutdown restart
Oder braucht man nich einen shutdown restart vor der CUL1_STACK Definition?

@Telekatz: Welche Modulversionen nutzt Du?

Gruß Arnd

Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 27 Juni 2017, 21:14:11
Hi,

hier mal meine definition für 4x Zwave:


define mCUL ZWCUL /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00 00000000 01
attr mCUL dataRate 100k

define SCC1 STACKABLE mCUL
define z100k ZWCUL FHEM:DEVIO:SCC1:9600 00000000 01
attr z100k dataRate 100k

define SCC2 STACKABLE z100k
define z40k ZWCUL FHEM:DEVIO:SCC2:9600 00000000 01
attr z40k dataRate 40k

define SCC3 STACKABLE z40k
define z9k6 ZWCUL FHEM:DEVIO:SCC3:9600 00000000 01
attr z9k6 dataRate 9600


Läuft bei mir unter Linux einwandfrei und sollte auch unter Windows laufen. Sobald das erste/unterste Device sich vernünftig ansprechen lässt gibt es ja keine Probleme mehr mit dem Treiber, Zugriffsrechten oder sonstigen Betriebssystemspezifischen Sachen. Danach geht es ja nur darum die Nachrichten anhand der "*" zu zerlegen...

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 21:35:14
Hmm, nicht ganz:

#------------------------------------------------------------------------------
define 868MapleCUL CUL COM6@38400 1234
attr 868MapleCUL room MapleCUL
attr 868MapleCUL verbose 3
#------------------------------------------------------------------------------
define 433MapleCUL STACKABLE 868MapleCUL
attr 433MapleCUL room MapleCUL
attr 433MapleCUL verbose 3
#------------------------------------------------------------------------------


Lässt sich zwar der Maple ansprechen aber scheint etwas "durcheinander"-
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 27 Juni 2017, 21:40:59
Hi,
Da fehlt doch das Zwischendevice:

define 868MapleCul CUL COMx@38400 1234

define 868MapleCulStack STACKABLE 868MapleCul

define 433MapleCul CUL FHEM:DEVIO:868MapleCulStack:9600 0000

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 21:48:25
Hallo Arnd,
prüfe nach. Für obige Variante habe ich einen defekten erwischt.
Ein zweiter funktioniert mit STACKABLE_CC aber nicht mit STACKABLE
Device ist nit initialized sondern nur opened.


ZwischenDevice???
Probiere Dein Vorschlag aus...

Hoffe, wir sprechen alle von Locutus Dual CC1101-Version?

Grüße Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 21:54:09
Zitat#------------------------------------------------------------------------------
define 868MapleCUL CUL COM12@38400 1234
define 868MapleCulStack STACKABLE 868MapleCul
attr 868MapleCUL room MapleCUL
attr 868MapleCUL verbose 3
#------------------------------------------------------------------------------
#define 433MapleCUL STACKABLE 868MapleCUL
define 433MapleCul CUL FHEM:DEVIO:868MapleCulStack:9600 0000
attr 433MapleCUL room MapleCUL
attr 433MapleCUL verbose 3
#------------------------------------------------------------------------------

erzeugt:
ZitatMessages collected while initializing FHEM:
configfile: 868MapleCul is not a valid device
./log/fhem.save: Please define 433MapleCUL first
Please define 433MapleCUL first
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 21:56:32
Hallo Arnd,
hast Du die Referenz auf auf das "Zwischen-Device" ?

Ok, habe mich auch noch nicht in diese Thematik eingelesen ....  :(

Solange es mit STACKABLE_CC funktioniert ...

Muss auch erst mal herausfinden, warum mein "Aussetzer" seine CC's nicht mehr mag.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 27 Juni 2017, 21:57:06
Hi,
Groß-Kleinschreibung beachten...
Andreas.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 27 Juni 2017, 21:58:03
Mal 868MapleCUL mal 868MapleCul - bei 433 analog ;-)

Mit Zwischendevice meine ich den Stack. Bei einem Doppel Maple het man in FHEM ja dann drei Devices (CUL1, Stack und CUL2)

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Juni 2017, 22:06:00
Ah, schon spät .., danke.

Zitat2017.06.27 22:01:44 1: PERL WARNING: Second Write attempted before First is done at ./FHEM/DevIo.pm line 128.
2017.06.27 22:01:44 1: PERL WARNING: Use of uninitialized value $written in numeric ne (!=) at C:/Strawberry/perl/site/lib/Win32/SerialPort.pm line 1580.
2017.06.27 22:01:50 1: Cannot init COM12, ignoring it (868MAPLECUL)
2017.06.27 22:01:50 3: Opening 433MAPLECUL device FHEM:DEVIO:868MAPLECULSTACK:38400
2017.06.27 22:01:50 1: Cannot init FHEM:DEVIO:868MAPLECULSTACK:38400, ignoring it (433MAPLECUL)

Zitat#------------------------------------------------------------------------------
define 868MAPLECUL CUL COM12@38400 1234
define 868MAPLECULSTACK STACKABLE 868MAPLECUL
attr 868MAPLECUL room MapleCUL
attr 868MAPLECUL verbose 3
#------------------------------------------------------------------------------
#define 433MAPLECUL STACKABLE 868MAPLECUL
define 433MAPLECUL CUL FHEM:DEVIO:868MAPLECULSTACK:38400 0000
attr 433MAPLECUL room MapleCUL
attr 433MAPLECUL verbose 3
#------------------------------------------------------------------------------

Bin davon ausgegangen dass das 433MAPLECUL-Device auch 38400 kann,
das scheint aber nicht der generelle Fehler zu sein...

Also erst mal wieder zurück auf STACKABLE_CC.

Dann:
ZitatInternals:
   DEF        868MAPLECUL
   IODev      868MAPLECUL
   NAME       433MAPLECUL
   NOTIFYDEV  868MAPLECUL
   NR         6
   NTFY_ORDER 50-433MAPLECUL
   STATE      Defined
   TYPE       STACKABLE
Attributes:
   room       MapleCUL
   verbose    3

Der 433MAPLECUL ist nur noch "defined" aber nicht mehr "initialized" .... :(

Zitat#------------------------------------------------------------------------------
define 868MAPLECUL CUL COM12@38400 1234
#define 868MAPLECULSTACK STACKABLE 868MAPLECUL
attr 868MAPLECUL room MapleCUL
attr 868MAPLECUL verbose 3
#------------------------------------------------------------------------------
define 433MAPLECUL STACKABLE 868MAPLECUL
#define 433MAPLECUL CUL FHEM:DEVIO:868MAPLECULSTACK:38400 0000
attr 433MAPLECUL room MapleCUL
attr 433MAPLECUL verbose 3
#------------------------------------------------------------------------------

Ok, "_CC" fehlt... nachgetragen und neu gestartet:

ZitatCUL
868MAPLECUL
   
Initialized
STACKABLE_CC
433MAPLECUL
   
Defined

... trotzdem.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 28 Juni 2017, 05:19:28
Hi,
also es hat jetzt unter Linux funktioniert. Ich habe tatsächlich erst alle Stackable_cc Devices gelöscht und dann shutdown restart und dann die Stackable und CUL definiert ;-)

Hier meine Beispiele:
Meine Definitionen:

define CULMGrau868 CUL /dev/serial/by-id/usb-STM32_MapleCUL_6bfbb14f-if00@38400 1432
attr CULMGrau868 group Gateways
attr CULMGrau868 icon cul_868
attr CULMGrau868 model CUN
attr CULMGrau868 rfmode SlowRF
attr CULMGrau868 room Arbeitszimmer,Hardware,Maple
attr CULMGrau868 verbose 5

define CULMGrau868Stack STACKABLE CULMGrau868
attr CULMGrau868Stack room Arbeitszimmer,Hardware,Maple

define CULMGrau433 CUL FHEM:DEVIO:CULMGrau868Stack:9600 0000
attr CULMGrau433 group Gateways
attr CULMGrau433 icon cul_cul
attr CULMGrau433 model CUN
attr CULMGrau433 rfmode SlowRF
attr CULMGrau433 room Arbeitszimmer,Hardware,Maple
attr CULMGrau433 verbose 5

list des ersten Maple:

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_6bfbb14f-if00@38400 1432
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_6bfbb14f-if00@38400
   FD         77
   FHTID      1432
   NAME       CULMGrau868
   NR         362
   PARTIAL
   STACKED    CULMGrau868Stack
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 868MHz)
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-28 05:18:25   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:8dB
     2017-06-28 05:18:33   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2017-06-28 05:13:34   state           Initialized
     2017-06-28 05:18:44   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 868MHz)
Attributes:
   group      Gateways
   icon       cul_868
   model      CUN
   rfmode     SlowRF
   room       Arbeitszimmer,Hardware,Maple
   verbose    5

list des Stack auf dem ersten Maple:

Internals:
   DEF        CULMGrau868
   IODev      CULMGrau868
   NAME       CULMGrau868Stack
   NOTIFYDEV  CULMGrau868
   NR         363
   NTFY_ORDER 50-CULMGrau868Stack
   STATE      Defined
   TYPE       STACKABLE
Attributes:
   room       Arbeitszimmer,Hardware,Maple

list des zweiten Maple:

Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        FHEM:DEVIO:CULMGrau868Stack:9600 0000
   DeviceName FHEM:DEVIO:CULMGrau868Stack:9600
   FD         77
   FHTID      0000
   IODev      CULMGrau868Stack
   IODevPort  9600
   IOReadFn   STACKABLE_IOReadFn
   NAME       CULMGrau433
   NR         364
   PARTIAL
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 433MHz)
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-28 05:15:27   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB
     2017-06-28 05:15:37   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2017-06-28 05:13:34   state           Initialized
     2017-06-28 05:15:51   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 433MHz)
Attributes:
   group      Gateways
   icon       cul_cul
   model      CUN
   rfmode     SlowRF
   room       Arbeitszimmer,Hardware,Maple
   verbose    5

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 28 Juni 2017, 10:09:38
Moin,

und jetzt mein nicht erfolgreicher Test unter Windows:

Grundsätzlich bleibt der gestackte CUL auf Status open.
Die raw Abfragen mittels vorgestelltem * auf dem ersten MAPLE gehen aber!

Defines:

define MAPLE CUL COM9@38400 2143
attr MAPLE icon cul_868
attr MAPLE model CUL
attr MAPLE rfmode SlowRF
attr MAPLE room Arbeitszimmer,Hardware,Maple
attr MAPLE verbose 5

define MAPLE_STACK STACKABLE MAPLE
attr MAPLE_STACK room Arbeitszimmer,Hardware,Maple

define MAPLE2 CUL FHEM:DEVIO:MAPLE_STACK:9600 0000
attr MAPLE2 icon cul_cul
attr MAPLE2 room Maple,Arbeitszimmer,Hardware
attr MAPLE2 model CUL
attr MAPLE2 rfmode SlowRF
attr MAPLE2 verbose 5


Hier die list der Devices:
Erster MAPLE:

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        COM9@38400 2143
   DeviceName COM9@38400
   FHTID      2143
   MAPLE_MSGCNT 1
   MAPLE_TIME 2017-06-28 09:59:40
   NAME       MAPLE
   NR         35
   PARTIAL
   RAWMSG     *V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)
   STACKED    MAPLE_STACK
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-28 10:00:53   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2017-06-28 10:01:07   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2017-06-28 10:03:07   raw             *C0D = 10 / 16
     2017-06-28 09:59:40   state           Initialized
     2017-06-28 10:01:11   version         V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)
Attributes:
   icon       cul_868
   model      CUL
   rfmode     SlowRF
   room       Arbeitszimmer,Hardware,Maple
   verbose    5


Stack:

Internals:
   DEF        MAPLE
   IODev      MAPLE
   NAME       MAPLE_STACK
   NOTIFYDEV  MAPLE
   NR         37
   NTFY_ORDER 50-MAPLE_STACK
   STATE      Defined
   TYPE       STACKABLE
Attributes:
   room       Arbeitszimmer,Hardware,Maple


Zweiter MAPLE:

Internals:
   CMDS
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        FHEM:DEVIO:MAPLE_STACK:9600 0000
   DeviceName FHEM:DEVIO:MAPLE_STACK:9600
   FHTID      0000
   IODevRxBuffer V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)

   IOReadFn   STACKABLE_IOReadFn
   NAME       MAPLE2
   NR         39
   PARTIAL
   STATE      opened
   TYPE       CUL
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-28 10:01:42   cmds            No answer
     2017-06-28 09:59:39   state           opened
     2017-06-28 10:01:35   version         No answer
Attributes:
   icon       cul_cul
   model      CUL
   rfmode     SlowRF
   room       Maple,Arbeitszimmer,Hardware
   verbose    5


und hier das passende fhem.log:

2017.06.28 09:59:39 3: initialUsbCheck return value: This command is not yet supported on windows
2017.06.28 09:59:39 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.06.28 09:59:39 0: Featurelevel: 5.8
2017.06.28 09:59:39 0: Server started with 40 defined entities (fhem.pl:14348/2017-05-22 perl:5.024001 os:MSWin32 user:Arnd pid:12224)
2017.06.28 09:59:40 5: CUL/RAW: /*V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)

2017.06.28 09:59:40 4: CUL_Parse: MAPLE *V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)
2017.06.28 09:59:40 5: MAPLE: dispatch *V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)
2017.06.28 10:00:53 5: SW: C0D
2017.06.28 10:00:53 5: CUL/RAW (ReadAnswer): C0D = 21 / 33

2017.06.28 10:00:53 5: SW: C0E
2017.06.28 10:00:53 5: CUL/RAW (ReadAnswer): C0E = 65 / 101

2017.06.28 10:00:53 5: SW: C0F
2017.06.28 10:00:53 5: CUL/RAW (ReadAnswer): C0F = 6A / 106

2017.06.28 10:00:53 5: SW: C10
2017.06.28 10:00:53 5: CUL/RAW (ReadAnswer): C10 = 57 / 87

2017.06.28 10:00:53 5: SW: C1B
2017.06.28 10:00:53 5: CUL/RAW (ReadAnswer): C1B = 07 /  7

2017.06.28 10:00:53 5: SW: C1D
2017.06.28 10:00:53 5: CUL/RAW (ReadAnswer): C1D = 90 / 144

2017.06.28 10:01:07 5: SW: ?
2017.06.28 10:01:07 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *

2017.06.28 10:01:11 5: SW: V
2017.06.28 10:01:11 5: CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)

2017.06.28 10:01:30 5: SW: C0D
2017.06.28 10:01:35 5: SW: V
2017.06.28 10:01:39 5: SW: C0D
2017.06.28 10:01:42 5: SW: ?
2017.06.28 10:02:05 5: SW: *V
2017.06.28 10:02:05 5: CUL/RAW (ReadAnswer): *V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)

2017.06.28 10:02:22 5: SW: *?
2017.06.28 10:02:22 5: CUL/RAW (ReadAnswer): *? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z

2017.06.28 10:03:07 5: SW: *C0D
2017.06.28 10:03:07 5: CUL/RAW (ReadAnswer): *C0D = 10 / 16


Ich glaube hier ist unter Windows entweder meine Config schlecht,
oder das STACKABLE Modul hat unter Win ein generelles Problem!?

Gruß Arnd
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhem-challenge am 29 Juni 2017, 09:37:56
Hallo Zusammen,

irgendwie scheint noch ein kleiner Bug zu existieren mit der a-Culfw vom 30.3.2017.

Wenn ich via USB die IP vergebe, ist die auch persitent. Auch DHCP Flag ist disabled. Ein "Rin" gibt mir auch die korrekte IP aus.
Rin
192.168.100.241
Rin
192.168.100.241



Wenn ich mir aber am Debugport des miniMaple die Ausgabe anschaue, steht dort als IP:  IP : 0.29.0.32 und nicht die eingestellte "192.168.100.241". Dann wieder am USB Port angeschlossen und "Rin" gemacht, dort kommt wieder wie erwartet "192.168.100.241".

Ist das nur ein Ausgabefehler ??


-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar 30 2017 16:12:11 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.

===== W5500 NET CONF : Static =====
MAC : 00:80:41:2B:AA:6E
IP : 0.29.0.32
GW : 192.168.100.254
SN : 192.168.100.241
=======================================
-I- Detected CC0: PN 0x00  VER 0x14
-I- Not detected CC1: PN 0x00  VER 0x00
-I- Detected CC2: PN 0x00  VER 0x14
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Detected ethernet
-I- init USB
-I- init Complete
0:TCP server start
0:Socket opened
1:TCP server start
1:Socket opened
2:TCP server start
2:Socket opened
0:Listen, TCP server, port [2323]
1:Listen, TCP server, port [2324]
2:Listen, TCP server, port [2325]



Viele Grüße!


Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 29 Juni 2017, 18:55:26
Zitat von: fhem-challenge am 29 Juni 2017, 09:37:56
SN : 192.168.100.241
Ich tippe eher auf die ungewöhnliche Subnetzmaske.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 29 Juni 2017, 20:54:00
Zitat von: fhem-challenge am 29 Juni 2017, 09:37:56
Wenn ich via USB die IP vergebe, ist die auch persitent. Auch DHCP Flag ist disabled. Ein "Rin" gibt mir auch die korrekte IP aus.
Rin
192.168.100.241
Rin
192.168.100.241

Und ich tippe darauf, dass du den Befehl zum setzen der IP Adresse mit dem Befehl zum setzen der Subnetzmaske verwechselt hast.
Die IP Adresse wird mit Wiaxxx.xxx.xxx.xxx/Ria geschrieben/gelesen. Rin liest die Subnetzmaske.
Titel: Antw:Selbstbau CUN
Beitrag von: Wallmeier am 29 Juni 2017, 22:10:25
Zitat von: Telekatz am 21 Dezember 2016, 22:25:02
Zusätzlich würde ich noch einen weiteren Steckplatz für ein Transceivermodul vorschlagen. Da an diesem Steckplatz I2C verfügbar ist, könnte man dort auch ein 1-Wire Modul betreiben (Bild im Anhang, ganz rechts).

@Telekatz: Nachdem jetzt der 1-Wire-Support in der Firmware hinzugekommen ist, die Frage ob es das abgebildete 1-Wire-Modul fertig zu kaufen gibt bzw. das Platinenlayout veröffentlicht wurde?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 29 Juni 2017, 22:28:45
Cool: https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/MapleCUN
Zitat- ARM Models:
  - Add onewire
  - Improve hardware autodetection
- MapleCUN: Add 3rd SlowRF transceiver

Damit machen dann ggf auch 2 433MHz Module Sinn...

Funktioniert das dann auf dem Slot2 ? (Also das dritte Modul?)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 29 Juni 2017, 23:17:57
Es funktioniert an den ersten drei erkannten Modulen.

Ich habe mit dieser Version auch die automatische Erkennung der Module überarbeitet. Jetzt ist es auch möglich, einen Slot unbestückt zu lassen und die nachfolgenden Slots trotzdem verwenden zu können.

Wenn alle 4 Slots belegt sind, funktioniert SlowRF an Slot0, Slot1 und Slot2. Ist irgend ein beliebiger Slot unbelegt, funktioniert es an den übrigen 3 Slots. Allerdings funktioniert das Senden von SlowRF nicht am letzten Slot, da dort kein Output Pin angeschlossen ist.

Zitat von: Wallmeier am 29 Juni 2017, 22:10:25
@Telekatz: Nachdem jetzt der 1-Wire-Support in der Firmware hinzugekommen ist, die Frage ob es das abgebildete 1-Wire-Modul fertig zu kaufen gibt bzw. das Platinenlayout veröffentlicht wurde?
Das Modul gibt es nicht fertig zu kaufen. Reicht dir der Schaltplan oder brauchst du auch noch die Gerber Dateien?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 30 Juni 2017, 20:36:28
Anbei der Schaltplan und die Gerber Dateien.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Wallmeier am 30 Juni 2017, 21:39:30
Kurze Rückfrage zu dem Schaltplan - welchen Wert soll der Widerstand R4 haben?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 30 Juni 2017, 22:19:08
Das hängt davon ab, ob die angeschlossenen 1-Wire Devices parasitär versorgt werden sollen und wie groß deren Strombedarf ist. Der Widerstand soll dann den Strom begrenzen.
Das Datenblatt vom DS2482-100 gibt dazu auch keine konkreten Empfehlungen. Ich würde mal 100 Ohm vorschlagen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 30 Juni 2017, 23:45:03
Zitat von: Telekatz am 29 Juni 2017, 23:17:57
Es funktioniert an den ersten drei erkannten Modulen.

Ich habe mit dieser Version auch die automatische Erkennung der Module überarbeitet. Jetzt ist es auch möglich, einen Slot unbestückt zu lassen und die nachfolgenden Slots trotzdem verwenden zu können.

Wenn alle 4 Slots belegt sind, funktioniert SlowRF an Slot0, Slot1 und Slot2. Ist irgend ein beliebiger Slot unbelegt, funktioniert es an den übrigen 3 Slots. Allerdings funktioniert das Senden von SlowRF nicht am letzten Slot, da dort kein Output Pin angeschlossen ist.

Danke das in der Tat cool. Ich habe mal das Wiki aktualisiert. Ob das noch aktuell ist weiß ich nicht: "KOPP und MBUS funktionieren nur an CC0." (nutze ich auch nicht!)

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 01 Juli 2017, 10:27:57
Hallo Telekatz,
Zitat von: Telekatz am 06 Februar 2017, 19:15:56
Ich hatte das ursprünglich in der Bauform eines RF1100SE Moduls geplant. Es sollte dann anstatt eines Transceivermoduls verwendet werden.
was ist das auf Deinem Modul (https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=70608;image) für ein Stecker? Ich denke mal, RM2,54 mm aber ich habe nur so was https://www.reichelt.de/Molex-Vielfachsteckverbinder/MOLEX-22057038/3/index.html?ACTION=3&LA=446&ARTICLE=185665&GROUPID=7981&artnr=MOLEX+22057038&SEARCH=Molex%2B2%252C54%2BStiftleiste gefunden.

Ggf. sehe ich für meine Platine den Molex PicoBlade (https://www.reichelt.de/Molex-Vielfachsteckverbinder/MOLEX-532610371/3/index.html?ACTION=3&LA=446&ARTICLE=186227&GROUPID=7981&artnr=MOLEX+532610371&SEARCH=molex%2Bpicoblade%2B1x3) vor: SMD, kann von außen gesteckt werden und das Ganze ist schön klein.

Danke + Gruß

PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 01 Juli 2017, 11:57:45
Zitat von: Ranseyer am 30 Juni 2017, 23:45:03
Danke das in der Tat cool. Ich habe mal das Wiki aktualisiert. Ob das noch aktuell ist weiß ich nicht: "KOPP und MBUS funktionieren nur an CC0." (nutze ich auch nicht!)
KOPP funktioniert immer noch nur an CC0. MBUS funktioniert jetzt an jedem Anschluss, allerdings nur insgesamt ein mal.

Zitat von: PeMue am 01 Juli 2017, 10:27:57
Hallo Telekatz,was ist das auf Deinem Modul (https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=70608;image) für ein Stecker?
Das ist dieser hier:
https://www.reichelt.de/Platinen-Steckverbinder/PSS-254-3W/3/index.html?ACTION=3&LA=446&ARTICLE=14910&GROUPID=7525&artnr=PSS+254%2F3W&SEARCH=pss3w (https://www.reichelt.de/Platinen-Steckverbinder/PSS-254-3W/3/index.html?ACTION=3&LA=446&ARTICLE=14910&GROUPID=7525&artnr=PSS+254%2F3W&SEARCH=pss3w)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 01 Juli 2017, 14:05:56
Hi Martin,
kannst Du auch mal STACKABLE auf Linux statt STACKABLE_CC aufnehmen?
Gerne mit meinen Codeblöcken oben ;-)
Danke und Gruß
Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 Juli 2017, 14:14:47
Zitatkannst Du auch mal STACKABLE auf Linux statt STACKABLE_CC aufnehmen?

-läuft das stabil ? (hast du eigentlich nen Vorteil festgestellt?)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 01 Juli 2017, 14:53:11
Ja läuft und der Vorteil sind andere CULs wie Zwave CUL ;-) Habe ich aber noch nicht.


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 01 Juli 2017, 15:03:58
Richtig,

Rudi hatte das ja extra "für mich" (wegen 4xfach Maple CUL mit ZWave) angepasst und daraus was generisches gemacht das mit eigentlich alles CUL varianten funktionieren sollte.
Ansonsten sollte es da ja keine weiteren Unterschiede geben bis auf die Tatsache das "Umsteiger" diese "Zwischendevice" weglassen...

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 02 Juli 2017, 23:14:35
Zitat von: juergs am 09 Juni 2017, 12:41:21
Ich habe diesen Bootloader hier für Locutus-Board  verwendet:

https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin)

Zusammen mit dieser Binary von hier:
https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507 (https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507)

Boot1 muss mit GND verbunden sein, ist die Lötbrücke auf der Unterseite der Platine, neben TX1 und RX1.
Beides mit FTDI-USB-Seriell-Wandler geflasht.
Diese Versionen  haben eine Abhängigkeit mit der Zuordnung der User-LED zum verwendeten I/O-Pin. 

Hallo Jürgen,
ich habe Roger Clarks Bootloader (https://github.com/rogerclarkmelbourne/STM32duino-bootloader) für den MapleCUL USB-Stick (https://forum.fhem.de/index.php/topic,60458.msg621959.html#msg621959) modifiziert:
#elif defined TARGET_GENERIC_F103_PC13

#define LED_BANK GPIOB
#define LED_PIN 1
#define LED_ON_STATE 0

// Button (if you have one)
#define BUTTON_BANK GPIOB
#define BUTTON_PIN 8
#define BUTTON_PRESSED_STATE 1


Entstanden ist die generic_boot20_pb1.bin Datei.
Um den Perpetual Bootloader Mode (http://youtu.be/rvNIeKuXsxM) zu verwenden, muss man eine winzige Modifikation am MapleCUL (https://forum.fhem.de/index.php/topic,60458.msg621959.html#msg621959) durchführen, nähmlich die Ports PB8 und BOOT0 (Pin 44 und 45) mit Lötzinn verbinden.
Magst Du bitte testen und Feedback geben?
Ich stehe nach wie vor auf Kriegsfuß mit diesem Bootloader. Es spielt keine Rolle, ob ich eine _BL.bin oder .bin Datei flashe, das System enumeriert kein neues USB-Gerät.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 03 Juli 2017, 18:02:02
Hallo locutus,

ZitatMagst Du bitte testen und Feedback geben?
Ja, gerne.

ZitatIch stehe nach wie vor auf Kriegsfuß mit diesem Bootloader. Es spielt keine Rolle, ob ich eine _BL.bin oder .bin Datei flashe, das System enumeriert kein neues USB-Gerät.
Also bei mir gingen die "xxx_BL.bin" - Binaries gar nicht -> gleiches Symptom: keine Enumeration der USB-COM-Ports beim Einstecken.

Der Bootloader von Roger Clark ermöglicht ja ein Programmieren aus der Arduino IDE. Deshalb kommt sofort nach dem Flashen des BLs und einem Reset
die Enumeration der USBs.

Bei mir gab es auch einen anderen Grund, warum es nicht direkt ging: eine unbeabsichtigte Brücke bei den Ports.
Das kann man nur mit sehr guter Lupe oder Mikroskop entdecken. Brücke weggekratzt -> Enumeration geht.

Ok, das LQFP48-Gehäuse ist nichts für Lötanfänger, das anfängliche genaueste Ausrichten der 4 äußeren Pins  entscheidet über die Qualität der Lötung mit Heißluft
der restlichen Pins. Ich verzinne die Pins der Platine vorher mit Lötzinn und ziehe es mit guter Entlötlitze wieder ab. Dann die 4 äußersten Pins  exakt ausrichten, dann anlöten.
Danach mit viel Flußmittel-Paste und Reflow-Heißluft die Pins des Chip anziehen lassen. Das überflüssige Flussmittel kann man hinterher wieder leicht
mit Leiterplatten-Reiniger entfernen.

Aber, wem sag ich das  ;)

Jürgen

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 03 Juli 2017, 18:24:06
Hallo Locutus,

habe bei meinem Board den Speicher vorsorglich gelöscht.
Vorher überzeugt, daß enumeriert wird ...
Dann Dein Bin-File geflasht: Ergebnis leider negativ. /edit: Das ist ok so, da ja der DFU-Boot-Modus aktiv ist!
Die Leuchtdiode blinkt im 0.5 s Takt. Beim Drücken des Reset-Buttons kurz etwas  schneller.
Sonst keine weitere Reaktion.

/edit: Das ist ok so, da ja der DFU-Boot-Modus aktiv ist! Der Bootloader generiert keine seriellen  COM-Ports.
Programmieren wäre nur mittels dfu-util-tool oder seriell über den Demonstrator möglich.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 03 Juli 2017, 18:57:48
Hallo Locutus,

nach dem Flashen des Bootloaders "generic_boot20_pc13.bin" kommt entgegen meiner Annahme
keine Reaktion der Seriellen. Dann einfach die "MapleCULx4.bin" hinzugeflasht ... und geht.
Nach Reset blinkt die blaue LED im bekannten Sekunden-Takt .... und die Ports erscheinen ...

Was ich nachher noch prüfen kann, ob beide BLs "standalone" wenigstens mit dfu-util / Arduino-IDE ansprechbar sind.

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 03 Juli 2017, 19:06:59
1.) generic_boot20_pb1.bin

-> Blink geht über die IDE zu flashen, ohne ein Button drücken zu müssen!

COM-Ports kommen, diesmal anders enumeriert ..... COM12/13/14

Archiving built core (caching) in: C:\Users\jschw\AppData\Local\Temp\arduino_cache_578362\core\core_Arduino_STM32_STM32F1_mapleMini_bootloader_version_original,cpu_speed_speed_72mhz_203eb828a61a67ce703c3870ede5d634.a
Sketch uses 12956 bytes (11%) of program storage space. Maximum is 110592 bytes.
Global variables use 2816 bytes of dynamic memory.
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...

Found it!

Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=259
Starting download: [##################################################] finished!
error resetting after download: usb_reset: could not reset device, win error: Das System kann die angegebene Datei nicht finden.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present

Done!

Resetting USB to switch back to runtime mode
timeout waiting for COM4 serial


Und die Led blinkt im Sketch vorgegebenen Takt...

"could not reset device" ist klar ... Die Schaltung dazu fehlt.
"COM4 serial" ist eine Dummy-Port-Angabe, die nicht existiert, aber zum Betrieb der IDE erforderlich zu sein scheint.Oder einfach die letzte Einstellung.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 03 Juli 2017, 19:19:38
Hallo Locutus,

wegen aud Deinem Board nicht belegtem PC13 blinkt der Bootloader nicht beim "generic_boot20_pc13.bin".
Deshalb die Änderung für  "generic_boot20_pb1.bin".

Ist mir so nicht direkt aufgefallen, weil ja die aculfw korrekt blinkt und
ich zuerst den Bootloader und sofort danach die "MapleCULx4.bin" geflasht habe.

Die PB1_Version wird hier leider  nicht vorgefertigt mit angeboten:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/STM32F1/binaries (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/STM32F1/binaries)

Allerdings funktioniert bei mir die Kombi: generic_boot20_pb1.bin + MapleCULx4.bin nicht.

Dann bleibt ja nur noch: "generic_boot20_pb1.bin" + "MapleCUNx4_W5500_BL.bin" ?

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 03 Juli 2017, 19:23:06
Dann bleibt ja nur noch: "generic_boot20_pb1.bin" + "MapleCUNx4_W5500_BL.bin" ?

Nein, geht auch nicht...
Nach Aus -und wieder Einstecken ....

/Edit: Evtl. verstrubelt sich das USB-Subsystem auch,  hätte noch klären sollen, ob es nach einem Reboot des Rechners funktioniert...
/Edit2: Der Bootloader wäre in diese Variante auch nicht erfoderlich, da er in der Binary schon enthalten ist.
/Edit3: "MapleCUNx4_W5100_BL.bin" alleine => Usb-Gerät wurde nicht erkannt. Mehrfach probiert...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 03 Juli 2017, 19:53:59
Deshalb bleibe ich bei meiner Kombi  ;)
... und verzichte auf das Blinken des Bootloaders, PC13 ist eh nicht verdrahtet.

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 03 Juli 2017, 22:11:12
Danke! Deine Kombi funktioniert leider bei mir nicht.

Zitat von: juergs am 03 Juli 2017, 18:02:02
Der Bootloader von Roger Clark ermöglicht ja ein Programmieren aus der Arduino IDE. Deshalb kommt sofort nach dem Flashen des BLs und einem Reset die Enumeration der USBs.
Damit wäre geklärt, warum die Enumeration nach dem flashen der a-culfw nicht klappt.

Die Funktionsweise ist in der README (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/README.md) beschrieben ...
ZitatOn "generic" boards, the USB reset (to force re-enumeration by the host), is triggered by reconfiguring USB line D+ (PA12) into GPIO mode, and driving PA12 low for a short period, before setting the pin back to its USB operational mode.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 03 Juli 2017, 22:19:47
ZitatDer Bootloader von Roger Clark ermöglicht ja ein Programmieren aus der Arduino IDE. Deshalb kommt sofort nach dem Flashen des BLs und einem Reset die Enumeration der USBs.
Nachdem der  Blink-Sketch geflasht wurde! Das Flashen des Bootloaders alleine bewirkt keine Einrichtung der Seriellen.



Ich habe beide Binaries einfach nacheinander geflasht, einfach mit "Back" wieder zurück in den Auswahl-Dialog.
Ein Reset hat dann ebenfalls "USB-Gerät nicht erkannt" - Meldung geliefert.
Vom USB-Bus getrennt wieder verbunden, geht .... (Evtl. nach einem Reboot?)

Vielleicht Windows Zeit geben den Maple-Clone zu erkennen...?

Diesmal wieder das Phänomen:
Ports COM 6,7,8 werden erzeugt und "V" reagiert auf Port COM7:

ZitatV 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_00 (F-Band: 868MHz)

ZitatDeine Kombi funktioniert leider bei mir nicht.
Ich habe jetzt 6..7 mal diese Versionen dieser Kombi geflasht, bei mir geht es!

Machen wir da doch noch etwas systematisch falsch?  Demonstrator?
Oder doch eher ein Hardware-Problem? USB-Kabel? Anderer Rechner?

Funktioniert BL + Arduino Blink-Sketch?

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 03 Juli 2017, 23:20:23
Zitat von: juergs am 03 Juli 2017, 19:19:38
Ist mir so nicht direkt aufgefallen, weil ja die aculfw korrekt blinkt und
ich zuerst den Bootloader und sofort danach die "MapleCULx4.bin" geflasht habe.

Zitat von: juergs am 03 Juli 2017, 22:19:47
Ich habe beide Binaries einfach nacheinander geflasht, einfach mit "Back" wieder zurück in den Auswahl-Dialog.
Wenn du das machst, kannst du dir das flashen vom Bootloader sparen, da du den mit MapleCULx4.bin sofort wieder überschreibst. Und wenn du so auch mit MapleCUNx4_W5500_BL.bin probiert hast, kann das nicht funktionieren, da die Firmware dann an die falsche Adresse im Flash geladen wird.

Mit dem Demonstrator wird entweder der Bootloader oder MapleCULx4.bin geflasht.

MapleCUNx4_W5500_BL.bin wird mit dem dfu-util geflasht.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 04 Juli 2017, 08:44:01
ZitatMapleCUNx4_W5500_BL.bin wird mit dem dfu-util geflasht.

Hallo Telekatz,
jetzt kommen wir der Sache näher. Meine Befürchtung mit den falschen Einsprungadressen  über den Demostrator
ist also bestätigt. (War der Meinung, das managed die Binary etwa wie bei IntelHex) ...

Dann wäre eigentlich nur die richtige Start-/Einsprungadresse zu bestimmen um es auch mit dem Demonstrator zum Laufen zu bringen?

Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 04 Juli 2017, 11:48:57
Zitat von: juergs am 04 Juli 2017, 08:44:01
Dann wäre eigentlich nur die richtige Start-/Einsprungadresse zu bestimmen um es auch mit dem Demonstrator zum Laufen zu bringen?
Die Einsprungadresse für den Bootloader ist 0x8002000, aber wozu sollte das gut sein? Es ist nicht sinnvoll, die Bootloader Variante mit dem Demonstrator zu laden. Dafür nimmt man die Variante ohne "_BL".

Für die Bootloader Variante ist es einfacher, Bootloader und dfu-util direkt über USB zu benutzen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 04 Juli 2017, 17:49:39
Hallo Ranseyer,

Zitat von: Ranseyer am 28 Februar 2017, 21:47:03
-ggf. funktioniert mySensors (Arduino-Pro mini oder Einzelteile)
  -NRF* Funkmodul
warum hast Du die LED an PD4 gehängt (siehe Schaltplan: https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=73243;image)?
Welches Signal willst Du anzeigen? Laut MySensors sollte Rx doch an Pin 6 = PD6 hängen?
Ich frage mich, was mit der LED angezeigt werden soll, wenn die doch im Gehäuse ist. Ggf. ist die nur für die Inbetriebnahme gut.

Danke + Gruß

PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 04 Juli 2017, 19:32:15
Hallo Zusammen,
dann fasse ich mal zusammen:


dfu-util hab ich bei mir hier entdeckt:
C:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\tools\win
Dort befinden sich auch die Tools für Linux etc.
Dort befindet sich die dfu-util.exe und auch Uploader über Serial und ST-Link.

Das Flashen mittels dfu-util kann auch wie unter Arduino erfolgen (Windows) :
C:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM4 1 1EAF:0003 C:\Users\<user>\AppData\Local\Temp\arduino_build_660111/Blink.ino.bin



REM
REM maple_upload.bat COM4 1 1EAF:0003 <pfad>/xxx.bin
REM
@echo off
rem: Note %~dp0 get path of this batch file
rem: Need to change drive if My Documents is on a drive other than C:
set driverLetter=%~dp0
set driverLetter=%driverLetter:~0,2%
%driverLetter%
cd %~dp0
java -jar maple_loader.jar %1 %2 %3 %4 %5 %6 %7 %8 %9

for /l %%x in (1, 1, 40) do (
  ping -w 50 -n 1 192.0.2.1 > nul
  mode %1 > nul
  if ERRORLEVEL 0 goto comPortFound
)

echo timeout waiting for %1 serial

:comPortFound


Die STMFlashLoader Demo.exe bietet die  0x800200 nicht als Adresslage an ...

@locutus:
hier eine Beispiel-USB-Switch-Schaltung: Beispiel-USB-Switch-Schaltung (http://www.olliw.eu/uploads/STM32-H103-sch.gif)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 04 Juli 2017, 22:40:40
Die USB DISC Schaltung ist mir bekannt. Auf meinem MapleCUL USB-Stick ist diese Schaltung nicht vorhanden.
Fakt ist, der generic_boot20_pb1.bin Bootloader erfüllt seinen Zweck. Ich sehe nach dem DFU Flashvorgang das typische Blinken der CUL-LED.
Mich interessiert der Trick, mit der Arduino IDE. Wie versetzt die Software PA12 von GPIO in den USB D+ Mode zurück?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 05 Juli 2017, 10:58:51
Zitat von: PeMue am 04 Juli 2017, 17:49:39
warum hast Du die LED an PD4 gehängt (siehe Schaltplan: https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=73243;image)?
Welches Signal willst Du anzeigen? Laut MySensors sollte Rx doch an Pin 6 = PD6 hängen?
Ich frage mich, was mit der LED angezeigt werden soll, wenn die doch im Gehäuse ist. Ggf. ist die nur für die Inbetriebnahme gut.

Die kann m.E. entfallen. Wie du schreibst sieht man die LED nur selten...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 05 Juli 2017, 12:20:27
Roger Clark antwortet darauf mit "Magic Sequence":
http://www.stm32duino.com/viewtopic.php?f=27&t=1133&sid=fe1129a80b86d714f050752f620918b2&start=10#p14201 (http://www.stm32duino.com/viewtopic.php?f=27&t=1133&sid=fe1129a80b86d714f050752f620918b2&start=10#p14201)

ZitatThe bootloader and the sketches are standalone.
The bootloader is loaded into the base of the flash, (which is some strange location like 0x800000) (I think this is also mapped to 0x0000000 but most places refer to 0x800000 as the start of flash)
When the MCU starts it runs the bootloader.
The bootloader code implements the USB DFU device, so that when you plug the board in, it will initially appear as the DFU device under libusb as Maple DFU
The bootloader waits about 1 second as the DFU device, but if the IDE doesn't connect and start uploading in this time, the bootloader checks if there is a valid sketch at 0x8005000 and if there is, the bootloader just jumps to that address and the sketch starts to run.
The Sketch has the USB serial code in it. So what is supposed to happen is that the PC notices that there is a different USB device (Maple Serial) when the sketch runs.
But to tell the PC that something has changed on the USB bus, the Maple mini uses the 2 transistors under the board, (under the USB connector) to toggle the USB DM line - in accordance with the USB spec related to device connection
Normally the PC will notice that the usb device has changed, and you will see the Maple Serial device (which is allocated a COM port)
In the IDE, when you select that COM port. - When you press upload, the IDE compiles, and then calls the Maple_upload.jar file
The jar file sends a magic sequence of chars via the COM port to the board (and toggled DTR)
The sketch code constantly listens for the magic sequence, and when that sequence is received, the sketch forces a reboot of the MCU, so that it runs the bootloader again, which appears as the DFU device (after first resetting the USB bus), so that dfu_util (which is called my maple_upload.jar), can send the sketch to the board
But, precisely why this sequence is not happening for you, I really don't know
It is possible for the sketch to over write the bootloader, but not just running normal code, you'd need to use the EEPROM library to specifically erase the pages of flash for the bootloader
(Note the new bootloader is smaller than the original one that comes pre-flashed on the boards from China. So the start address of the sketch for the old bootloader is 0x8005000 where as if the new bootloader is installed, the sketch is flashed into 0x8002000)
However these addresses are hard coded into the bootloader, so I don't think its possible to overwrite the bootloader with sketch code

Bootloader Sketch:
http://stm32duino.com/viewtopic.php?f=21&t=257&p=3229&hilit=updater#p3241 (http://stm32duino.com/viewtopic.php?f=21&t=257&p=3229&hilit=updater#p3241)

http://www.davidpilling.net/wiki/index.php/STM32 (http://www.davidpilling.net/wiki/index.php/STM32)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 05 Juli 2017, 19:39:52
DFU-Upload:
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/tools/linux/src/maple_loader/src/CliTemplate/DFUUploader.java (https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/tools/linux/src/maple_loader/src/CliTemplate/DFUUploader.java)

/* we need to ensure both RTS and DTR are low to start,
     then pulse DTR on its own. This is the reset signal
     maple responds to
  */


// try magic number
      serialPort.setRTS(true);
      serialPort.setDTR(true);
      try {
            Thread.sleep(50);
      } catch (InterruptedException e) {}
      serialPort.setDTR(false);
      try {
            Thread.sleep(50);
      } catch (InterruptedException e) {}
           serialPort.write("1EAF");
      try {
            Thread.sleep(50);
      } catch (InterruptedException e) {}
serialPort.dispose();


Magc Number:   serialPort.write("1EAF");

simple auto downloader (http://micromouseusa.com/?p=252)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 06 Juli 2017, 07:42:17
Hallo Jürgen,

so ganz kann ich Dir nicht folgen, aber ich sage mal, was ich meine, verstanden zu haben:
- man kann die Firmware per serieller Schnittstelle flashen (so wie den Bootloader),
  das bedeutet aber, dass man das Gerät zum Flashen öffnen muss oder
- man kann über USB flashen, dann braucht man aber die USB disconnect Schaltung (diese Schaltung
  hat locutus' USB Stick nicht) oder die Schaltung mit dem DTR/RTS Pin aus dem letzten Link

Soweit korrekt?
Bezüglich der zu verwendenden Software muss ich mich noch einlesen, aber bei mir funktioniert dfu-utils unter Windows 7. Ich will das Ganze aber noch auf einem Raspberry Pi testen.

Danke + Gruß

Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 06 Juli 2017, 11:13:56
Zitatman kann die Firmware per serieller Schnittstelle flashen (so wie den Bootloader)

Genau. Aber die Firmware muss passend ((für mit/ohne/welcher Bootloader)) compiliert worden sein!

An einem Linux Gerät sieht man beim USB Bootloader folgenden Ablauf:
-Für kurze Zeit gibt das Leaf-Labs Device
-Dann startet die "Applikation" und es erfolgt der USB-Disconnect, ohne den Disconnect wäre keine Kommunikation mit der Applikation möglich...

Fazit: Man kann an der HW etwas sparen, kann dann aber nicht per USB flashen. Natürlich könnte man die drei-4 Pins +einen Button zum Flashen nach außen legen, aber da würde ich lieber das USB Flashen ermöglichen... (Oder halt davon ausgehen dass das Gerät selten aktualisiert wird) 
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 06 Juli 2017, 12:31:31
Hallo Peter + Ranseyer,
ich glaube es gibt verschiedene Sichtweisen auf die Thematik,
je nach dem, von wo man kommt:

1. Man hat ein Maple-Clone vorliegen, dann ist es einfach, der Bootloader (z.B Maple) ist schon drauf -> DFU - USB Load  möglich.

2. Man baut ein Board selbst auf und benutzt einen fabrikfrischen Chip.
Hier fehlt ja der DFU-Bootloader noch. Der Chip besitzt, so wie ich es verstanden habe, nur einen eingebauten Bootloader der es nur über die Serielle-Verbindung ermöglicht,
die Vorraussetzungen zum weiteren USB-Flashen zu schaffen.

Ich versuche das heute Abend mal exakter aufzudröseln.
Trotzdem ist das Thema gerade als Neueinsteiger ziemlich verwirrend, insbesondere diese Mehrstufigkeit und der Variantereichtum der Infos, die im Internet herumgeisterten.

Was mich interessiert ist, wie man nach dem ersten Schritt nach dem seriellem Flashen des DFU-Bootloaders (MAPLE-DFU-Device)  und dem Flashen der Apllikation (Serielle Schnittstellen des Maples entstehen ... MAPLE-SERIAL-Device) 
programmatisch Zugriff auf das Device bekommt (libusb). (Also die Mischung zwischen dfu-util und MapleLoader/Demonstrator) ....

Grüße,
Jürgen


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 06 Juli 2017, 18:22:07
Hallo Jürgen,

ich bin mir nicht sicher ob du dir selbst das Leben schwer machst...

Zwei Varianten gibt es laut dir+mir:
-MAPLE: Genau an die Beschreibung von Telekatz halten ((kann man evt noch leicht verbessern)). Wer es anders machen will muss sich wohl selbst helfen
-Nackter Chip:
   -Wer das machen will muss sich einlesen und erst mal den USBBootloader draufbringen. Hat aber mit diesem Thread relativ wenig zu tun.
   -oder selbst kompilieren "ohne Bootloader"

Was ich damit sagen will: Denke es wäre besser einen neuen Thread aufzumachen um "andere STM32 Themen abseits des Maple zu diskutieren"

Was auch gut wäre wenn sich im Wiki noch mehr Leute einbringen würden. Ich habe z.B. den Input von Arnd noch nicht verarbeitet...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 06 Juli 2017, 22:28:00
Hallo Ranseyer,

Zitatich bin mir nicht sicher ob du dir selbst das Leben schwer machst...
Nein ganz sicher nicht, habe es ja "intuitiv" zu Laufen gebracht. Was mich stutzig macht ist, dass es z.B. bei Locutus in der gleichen Konstellation nicht
so läuft wie bei mir.

Zum Thread selbst:
ZitatSelbstbau CUN (MapleCUN)
Also alles was mit Selbstbau + Maple zu tun hat... oder liege ich mit meinem  Thema hier so daneben?
Es gibt ja wahrscheinlich mehr Leute, die auch mal mit dem Thema bei "0" , also auch mit den gleichen Hürden, anfangen werden ....

Zitat-MAPLE: Genau an die Beschreibung von Telekatz (und an Deine ge-) halten
Es hat bei mir nicht funktioniert, siehe auch umgekehrt Locutus und Peter.
Ich habe bis jetzt noch keine "_BL.bin" zum Laufen bringen können ....
Also gibt es schon Klärungsbedarf oder sagen wir mal Präzisierungsbedarf.  ;)

Grüße,
Jürgen

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 08 Juli 2017, 16:12:21
Hallo zusammen,

hat schon jemand mal die Stromaufnahme eines 4-fach mapleCUNs gemessen?
Hintergrund: Ich überlege mir, ob ich bei meiner Platine einen Schaltregler draufmachen soll, dazu bräuchte ich aber eine einigermaßen verlässliche Angabe.
lofutus' 1-fach mapleCUN (mit Netzwerk) braucht zwischen 170 ... 180 mA.

Danke + Gruß

Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 08 Juli 2017, 17:03:09
Ja Martin, steht doch auch im Wiki.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 08 Juli 2017, 17:28:24
Zitat von: RaspiLED am 08 Juli 2017, 17:03:09
Ja Martin, steht doch auch im Wiki.
Danke, habe das leider nicht gesehen.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 08 Juli 2017, 21:29:16
Hi,
kein Problem PeMue. Bin unterwegs gewesen, sonst hättest Du auch einen Link bekommen ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 08 Juli 2017, 22:11:30
Hi werte Mitstreiter!
Ich brauche Eure Hilfe!

Vorneweg, ich tippe auf falsche Register Einstellungen und nicht auf Hardwarefehler!

Mein Problem: Ein Duo Maple CUL von locutus empfängt alles auf 868 und 433, aber er will partout kein IT Code senden. Egal ob auf dem 1. 867er oder dem 2. 433er :-(

Im Log eines empfangenden 433er nanoCUL taucht nichts auf und die LED am Maple bleibt auch dunkel. In Eventmonitor des Maple FHEM sieht es auch normal aus.

Ich habe versucht mit raw e die Defaults herzustellen, aber der Fehler bleibt.

Sendet der NanoCUL zum Maple ist alles okay und ich sehe in beiden FHEM das IT Device schalten.
Ändere ich das IODev im Maple FHEM auf einen Signalduino433 ist auch alles okay und ich sehe in beiden FHEM das IT Device schalten.

Kann mir jemand sagen, wo die Register für das senden sind und wie die stehen müssen?

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 08 Juli 2017, 22:20:01
Hallo Arnd,

Zitat von: RaspiLED am 08 Juli 2017, 22:11:30
Mein Problem: Ein Duo Maple CUL von locutus empfängt alles auf 868 und 433, aber er will partout kein IT Code senden. Egal ob auf dem 1. 867er oder dem 2. 433er :-(
ist in der mapleCUN Software IT mitcompiliert? Was sagt denn
get <cul> cmds

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 08 Juli 2017, 22:55:43
Hi,
Naja eigentlich ist ja der Sinn vom Maple alles drin zu haben, obwohl Hörmann beim 868er in den Standard rein sollte ;-)

Aber würde er dann IT auch empfangen können? Kleines i für IT, oder?

Hier das list des 1. Maple auf 868:

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   CULM868_MSGCNT 1
   CULM868_TIME 2017-07-08 22:52:55
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00@38400 3214
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00@38400
   FD         64
   FHTID      3214
   NAME       CULM868
   NR         359
   PARTIAL
   RAWMSG     E0205624300000000003E
   RSSI       -43
   STACKED    CULM868_STACK
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-06-30 22:06:04   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2017-07-08 22:50:30   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2017-07-08 22:03:07   raw             No answer
     2017-07-08 22:52:55   state           Initialized
     2017-06-30 22:06:18   version         V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)
Attributes:
   group      Gateways
   icon       cul_868
   rfmode     SlowRF
   room       Arbeitszimmer,Hardware,Maple
   verbose    5

Hier das list des 2. Maple auf 433:

Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        FHEM:DEVIO:CULM868_STACK:9600 3434
   DeviceName FHEM:DEVIO:CULM868_STACK:9600
   FD         64
   FHTID      3434
   IODev      CULM868_STACK
   IODevPort  9600
   IOReadFn   STACKABLE_IOReadFn
   NAME       CULM433
   NR         361
   PARTIAL
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-07-08 22:51:53   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2017-07-08 22:52:12   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2017-06-30 22:00:05   raw             6
     2017-07-08 22:50:30   state           Initialized
     2017-07-08 22:52:26   version         V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)
Attributes:
   group      Gateways
   icon       cul_cul
   rfmode     SlowRF
   room       Arbeitszimmer,Hardware,Maple
   verbose    5

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 08 Juli 2017, 23:03:35
Zitat von: RaspiLED am 08 Juli 2017, 22:55:43
Aber würde er dann IT auch empfangen können? Kleines i für IT, oder?
So hätte ich gedacht: http://culfw.de/commandref#cmd_i
Aber ob er auch empfängt, weiß ich nicht.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 08 Juli 2017, 23:16:33
Hi,
Hier mal der Auszug aus dem Eventlog wenn der nanoCUL sendet:

2017.07.08 23:08:57 1 : in ATTR
2017.07.08 23:08:57 1 : in ATTR
2017.07.08 23:08:57 1 : in ATTR
2017-07-08 23:08:57 Global global ATTR IT_Schwarz_C IODev CULCH340
2017-07-08 23:09:10 IT IT_Schwarz_C on
2017.07.08 23:09:10 5 : SW: isr62017.07.08 23:09:10 5 : CUL/RAW (ReadAnswer): 6 2017-07-08 23:09:10 CUL CULCH340 raw: 6
2017.07.08 23:09:10 5 : SW: is00FFFFF0FF0F2017.07.08 23:09:10 5 : CUL/RAW (ReadAnswer): is00FFFFF0FF0F 2017-07-08 23:09:11 CUL CULCH340 raw: is00FFFFF0FF0F
2017.07.08 23:09:11 5 : SW: isr62017.07.08 23:09:11 5 : CUL/RAW (ReadAnswer): 6 2017-07-08 23:09:11 CUL CULCH340 raw: 6
2017.07.08 23:09:17 1 : in UNDEFINED2017.07.08 23:09:17 1 : in UNDEFINED2017.07.08 23:09:18 1 : in UNDEFINED2017.07.08 23:09:18 1 : in DEFINED2017.07.08 23:09:18 1 : in SAVE2017-07-08 23:09:18 Global global UNDEFINED CULCH340_2_STACKABLE STACKABLE CULCH340_2
2017-07-08 23:09:18 Global global DEFINED CULCH340_2_STACKABLE
2017-07-08 23:09:18 Global global SAVE
2017.07.08 23:09:18 1 : /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00 disconnected, waiting to reappear (CULM868)2017.07.08 23:09:18 1 : FHEM:DEVIO:CULM868_STACK:9600 disconnected, waiting to reappear (CULM433)2017-07-08 23:09:18 CUL CULM433 DISCONNECTED
2017-07-08 23:09:18 CUL CULM868 DISCONNECTED
2017.07.08 23:09:19 3 : Setting CULM868 serial parameters to 38400,8,N,1
2017.07.08 23:09:19 5 : SW: V
2017.07.08 23:09:19 5 : CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)
2017.07.08 23:09:19 5 : SW: ?
2017.07.08 23:09:19 5 : CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
2017-07-08 23:09:19 CUL CULM868 cmds: B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
2017.07.08 23:09:19 3 : CULM868: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2017.07.08 23:09:19 5 : SW: X21
2017.07.08 23:09:19 5 : SW: T01
2017.07.08 23:09:19 5 : CUL/RAW (ReadAnswer): 0000
2017.07.08 23:09:19 5 : GOT CUL fhtid: 0000
2017.07.08 23:09:19 2 : Setting CULM868 fhtid from 0000 to 3214
2017.07.08 23:09:19 5 : SW: T013214
2017-07-08 23:09:19 CUL CULM868 Initialized
2017.07.08 23:09:19 1 : /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00 reappeared (CULM868)
2017.07.08 23:09:19 5 : SW: V
2017.07.08 23:09:19 5 : CULM868 sending *V
2017.07.08 23:09:19 5 : SW: *V
2017.07.08 23:09:19 5 : CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)
2017.07.08 23:09:19 5 : SW: ?
2017.07.08 23:09:19 5 : CULM868 sending *?
2017.07.08 23:09:19 5 : SW: *?
2017.07.08 23:09:20 5 : CUL/RAW (ReadAnswer): ? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z
2017-07-08 23:09:20 CUL CULM433 cmds: b C F i A Z N E G M K L U Y R T V W X f z
2017.07.08 23:09:20 3 : CULM433: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.07.08 23:09:20 5 : SW: X21
2017.07.08 23:09:20 5 : CULM868 sending *X21
2017.07.08 23:09:20 5 : SW: *X21
2017.07.08 23:09:20 5 : SW: T01
2017.07.08 23:09:20 5
: CULM868 sending *T012017.07.08 23:09:20 5 : SW: *T012017.07.08 23:09:20 5 : CUL/RAW (ReadAnswer): 3214 2017.07.08 23:09:20 5 : GOT CUL fhtid: 32142017.07.08 23:09:20 2 : Setting CULM433 fhtid from 3214 to 34342017.07.08 23:09:20 5 : SW: T0134342017.07.08 23:09:20 5 : CULM868 sending *T0134342017.07.08 23:09:20 5 : SW: *T0134342017-07-08 23:09:20 CUL CULM433 Initialized
2017.07.08 23:09:20 1 : FHEM:DEVIO:CULM868_STACK:9600 reappeared (CULM433)2017-07-08 23:09:20 CUL CULM433 CONNECTED
2017-07-08 23:09:20 CUL CULM868 CONNECTED
2017-07-08 23:09:21 IT IT_Schwarz_C off
2017.07.08 23:09:21 5 : SW: isr62017.07.08 23:09:21 5 : CUL/RAW (ReadAnswer): 6 2017-07-08 23:09:21 CUL CULCH340 raw: 6
2017.07.08 23:09:21 5 : SW: is00FFFFF0FFF02017.07.08 23:09:21 5 : CUL/RAW (ReadAnswer): is00FFFFF0FFF0 2017-07-08 23:09:21 CUL CULCH340 raw: is00FFFFF0FFF0
2017.07.08 23:09:21 5 : SW: isr62017.07.08 23:09:21 5 : CUL/RAW (ReadAnswer): 6 2017-07-08 23:09:21 CUL CULCH340 raw: 6
2017-07-08 23:09:21 dummy Time_FP 2017-07-08 23:09
2017-07-08 23:09:22 at Time_Update Next: 23:10:21
2017.07.08 23:09:22 5 : CUL/RAW: /*i0554546E 2017.07.08 23:09:22 4 : CUL_Parse: CULM868 *i0554546E2017.07.08 23:09:22 5 : CULM868: dispatch *i0554546E2017.07.08 23:09:22 5 : CUL/RAW: /i0554546E 2017.07.08 23:09:22 4 : CUL_Parse: CULM433 i0554546E -192017.07.08 23:09:22 5 : CULM433: dispatch i0554542017.07.08 23:09:27 4 : CULM433 IT: message "i055454" (7)2017.07.08 23:09:27 4 : CULM433 IT: msgcode "00FFFFF0FFF0" (12) bin = 0000010101010100010101002017.07.08 23:09:27 5 : CULM433 IT: V1 housecode = 00FFFFF0FF  onoffcode = F02017-07-08 23:09:27 IT IT_Schwarz_C off
2017.07.08 23:09:27 1 : /dev/serial/by-path/platform-20980000.usb-usb-0:1.3.4:1.0 disconnected, waiting to reappear (CULCH340_2)2017.07.08 23:09:27 1 : PERL WARNING: Use of uninitialized value in split at ./FHEM/16_STACKABLE.pm line 101.2017.07.08 23:09:27 1 : PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/16_STACKABLE.pm line 102.2017.07.08 23:09:27 1 : PERL WARNING: Use of uninitialized value $dev in concatenation (.) or string at ./FHEM/16_STACKABLE.pm line 102.2017-07-08 23:09:28 CUL CULCH340_2 DISCONNECTED
2017-07-08 23:09:29 CUL CULCH340_2 cmds:  B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
2017-07-08 23:09:29 CUL CULCH340_2 Initialized
2017.07.08 23:09:29 1 : /dev/serial/by-path/platform-20980000.usb-usb-0:1.3.4:1.0 reappeared (CULCH340_2)2017.07.08 23:09:29 0 : Strange call for nonexistent <undefined>: ReadyFn2017-07-08 23:09:29 CUL CULCH340_2 CONNECTED

Ich sehe der nanoCUL CULCH340 sendet und der Maple433
Empfängt das auch ;-)

Und hier mal andersherum:

2017.07.08 23:14:47 1 : in ATTR
2017.07.08 23:14:47 1 : in ATTR
2017.07.08 23:14:47 1 : in ATTR
2017-07-08 23:14:47 Global global ATTR IT_Schwarz_C IODev CULM433
2017-07-08 23:14:54 IT IT_Schwarz_C on
2017.07.08 23:14:54 5 : SW: isr62017.07.08 23:14:54 5 : CULM868 sending *isr62017.07.08 23:14:55 5 : SW: *isr62017.07.08 23:14:55 5 : CUL/RAW (ReadAnswer): 6 2017-07-08 23:14:55 CUL CULM433 raw: 6
2017.07.08 23:14:55 5 : SW: is00FFFFF0FF0F2017.07.08 23:14:55 5 : CULM868 sending *is00FFFFF0FF0F2017.07.08 23:14:55 5 : SW: *is00FFFFF0FF0F2017.07.08 23:14:55 5 : CUL/RAW (ReadAnswer): is00FFFFF0FF0F 2017-07-08 23:14:55 CUL CULM433 raw: is00FFFFF0FF0F
2017.07.08 23:14:55 5 : SW: isr62017.07.08 23:14:55 5 : CULM868 sending *isr62017.07.08 23:14:55 5 : SW: *isr62017.07.08 23:14:55 5 : CUL/RAW (ReadAnswer): 6 2017-07-08 23:14:55 CUL CULM433 raw: 6
2017-07-08 23:15:00 IT IT_Schwarz_C off
2017.07.08 23:15:00 5 : SW: isr62017.07.08 23:15:00 5 : CULM868 sending *isr62017.07.08 23:15:00 5 : SW: *isr62017.07.08 23:15:00 5 : CUL/RAW (ReadAnswer): 6 2017-07-08 23:15:00 CUL CULM433 raw: 6
2017.07.08 23:15:00 5 : SW: is00FFFFF0FFF02017.07.08 23:15:00 5 : CULM868 sending *is00FFFFF0FFF02017.07.08 23:15:00 5 : SW: *is00FFFFF0FFF02017.07.08 23:15:00 5 : CUL/RAW (ReadAnswer): is00FFFFF0FFF0 2017-07-08 23:15:01 CUL CULM433 raw: is00FFFFF0FFF0
2017.07.08 23:15:01 5 : SW: isr62017.07.08 23:15:01 5 : CULM868 sending *isr62017.07.08 23:15:01 5 : SW: *isr62017.07.08 23:15:01 5 : CUL/RAW (ReadAnswer): 6 2017-07-08 23:15:01 CUL CULM433 raw: 6

Maple sendet laut Log, aber niemand hört was und die Steckdose bleibt aus ;-(

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 09 Juli 2017, 18:48:38
Hallo,
Also noch keiner eine Idee?
Dann liefere ich jetzt mal die Registerwerte:


get CULM866 raw C99
0D2E2D07D3913D04

Hat jemand Vergleiche von einem Maple?


get CULM433 raw C99
? ( is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z

Warum sagt der mir er kennt C und bringt dann nur den allgemeinen Fehler? Schon klar die Register lese ich auf dem ersten Maple, aber dann sollten wir vielleicht die Commandos einfach von *C auf C routen, oder?

Hier mal als Vergleich ein nanoCUL 433:

get CULCH340 raw C99
0D2E2D07D3913D04

Tja da sehe ich nix!

Kann ich andere Register liefern?
@Telekatz: Hast Du eine Idee?

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 09 Juli 2017, 20:33:41
Zitat von: RaspiLED am 09 Juli 2017, 18:48:38

get CULM433 raw C99
? ( is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z

Warum sagt der mir er kennt C und bringt dann nur den allgemeinen Fehler? Schon klar die Register lese ich auf dem ersten Maple, aber dann sollten wir vielleicht die Commandos einfach von *C auf C routen, oder?
Jeder Transceiver hat seine eigenen Register, die er mit C ausgibt.

Bei meinem Maple funktioniert Senden und Empfangen von IT, deshalb kann ich deinen Fehler nicht nachvollziehen.

Funktioniert denn das Senden, wenn du das IODev deines IT Geräts auf den CULM868 umstellst?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 09 Juli 2017, 20:35:50
Hi,
Nee auch nicht, dass habe ich auch getestet.
Aber warum kann ich dann die C99 auf dem zweiten per STACKABLE (nicht STACKABLE_CC)nicht auslesen? Meinst Du die Firmware ist buggy drauf?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 09 Juli 2017, 20:45:41
Ja, jetzt bin ich baff!


17.07.09 20:36:41 5: SW: C99
2017.07.09 20:36:41 5: CUL/RAW (ReadAnswer): 0D2E2D07D3913D04

2017.07.09 20:36:42 1: /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00 disconnected, waiting to reappear (CULM868)
2017.07.09 20:36:42 1: FHEM:DEVIO:CULM868_STACK:9600 disconnected, waiting to reappear (CULM433)
2017.07.09 20:36:42 3: Setting CULM868 serial parameters to 38400,8,N,1
2017.07.09 20:36:42 5: SW: V
2017.07.09 20:36:42 5: CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)

2017.07.09 20:36:42 5: SW: ?
2017.07.09 20:36:42 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *

2017.07.09 20:36:42 3: CULM868: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2017.07.09 20:36:42 5: SW: X21
2017.07.09 20:36:42 5: SW: T01
2017.07.09 20:36:42 5: CUL/RAW (ReadAnswer): 3434

2017.07.09 20:36:42 5: GOT CUL fhtid: 3434
2017.07.09 20:36:42 2: Setting CULM868 fhtid from 3434 to 3214
2017.07.09 20:36:42 5: SW: T013214
2017.07.09 20:36:42 1: /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00 reappeared (CULM868)
2017.07.09 20:36:42 5: SW: V
2017.07.09 20:36:43 5: CULM868 sending *V
2017.07.09 20:36:43 5: SW: *V
2017.07.09 20:36:43 5: CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)

2017.07.09 20:36:43 5: SW: ?
2017.07.09 20:36:43 5: CULM868 sending *?
2017.07.09 20:36:43 5: SW: *?
2017.07.09 20:36:43 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z

2017.07.09 20:36:43 3: CULM433: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.07.09 20:36:43 5: SW: X21
2017.07.09 20:36:43 5: CULM868 sending *X21
2017.07.09 20:36:43 5: SW: *X21
2017.07.09 20:36:43 5: SW: T01
2017.07.09 20:36:43 5: CULM868 sending *T01
2017.07.09 20:36:43 5: SW: *T01
2017.07.09 20:36:43 5: CUL/RAW (ReadAnswer): 3214

2017.07.09 20:36:43 5: GOT CUL fhtid: 3214
2017.07.09 20:36:43 2: Setting CULM433 fhtid from 3214 to 3434
2017.07.09 20:36:43 5: SW: T013434
2017.07.09 20:36:43 5: CULM868 sending *T013434
2017.07.09 20:36:43 5: SW: *T013434
2017.07.09 20:36:43 1: FHEM:DEVIO:CULM868_STACK:9600 reappeared (CULM433)
2017.07.09 20:37:02 5: SW: C99
2017.07.09 20:37:02 5: CULM868 sending *C99
2017.07.09 20:37:02 5: SW: *C99
2017.07.09 20:37:02 5: CUL/RAW (ReadAnswer): 0D2E2D07D3913D04
320000060010B071
57C43023B9000700
18146C070090876B

2017.07.09 20:37:03 5: CUL/RAW: /*F85611EF2C161F41
*00597F3F88310B00

2017.07.09 20:37:03 4: CUL_Parse: CULM868 *F85611EF2C161F41
2017.07.09 20:37:03 5: CULM868: dispatch *F85611EF2C161F41
2017.07.09 20:37:03 5: CUL/RAW: 320000060010B071
57C43023B9000700
18146C070090876B
/F85611EF2C161F41

2017.07.09 20:37:03 4: CUL_Parse: CULM433 320000060010B071
2017.07.09 20:37:03 5: CULM433: dispatch 320000060010B071
2017.07.09 20:37:03 3: CULM433: Unknown code 320000060010B071, help me!
2017.07.09 20:37:03 4: CUL_Parse: CULM433 57C43023B9000700
2017.07.09 20:37:03 5: CULM433: dispatch 57C43023B9000700
2017.07.09 20:37:03 3: CULM433: Unknown code 57C43023B9000700, help me!
2017.07.09 20:37:03 4: CUL_Parse: CULM433 18146C070090876B
2017.07.09 20:37:03 5: CULM433: dispatch 18146C070090876B
2017.07.09 20:37:03 3: CULM433: Unknown code 18146C070090876B, help me!
2017.07.09 20:37:03 4: CUL_Parse: CULM433 F85611EF2C161F41
2017.07.09 20:37:03 5: CULM433: dispatch 810f04xx0101a00185611e00f2c161f41
2017.07.09 20:37:03 4: CUL_Parse: CULM868 *00597F3F88310B00
2017.07.09 20:37:03 5: CULM868: dispatch *00597F3F88310B00
2017.07.09 20:37:03 5: CUL/RAW: /00597F3F88310B00

2017.07.09 20:37:03 4: CUL_Parse: CULM433 00597F3F88310B00
2017.07.09 20:37:03 5: CULM433: dispatch 00597F3F88310B00
2017.07.09 20:37:03 3: CULM433: Unknown code 00597F3F88310B00, help me!
2017.07.09 20:37:03 1: /dev/serial/by-path/platform-20980000.usb-usb-0:1.3.4:1.0 disconnected, waiting to reappear (CULCH340_2)
2017.07.09 20:37:03 1: /dev/serial/by-path/platform-20980000.usb-usb-0:1.3.4:1.0 reappeared (CULCH340_2)
2017.07.09 20:37:03 0: Strange call for nonexistent <undefined>: ReadyFn
2017.07.09 20:37:28 5: SW: *C99
2017.07.09 20:37:28 5: CUL/RAW (ReadAnswer): *0D2E2D07D3913D04
*320000060010B071
*57C43023B9000700
*18146C070090876B

2017.07.09 20:37:28 1: CULCH340_2_STACKABLE: no client device assigned
2017.07.09 20:37:28 1: CULCH340_2_STACKABLE: no client device assigned
2017.07.09 20:37:28 1: /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00 disconnected, waiting to reappear (CULM868)
2017.07.09 20:37:28 1: FHEM:DEVIO:CULM868_STACK:9600 disconnected, waiting to reappear (CULM433)
2017.07.09 20:37:29 3: Setting CULM868 serial parameters to 38400,8,N,1
2017.07.09 20:37:29 5: SW: V
2017.07.09 20:37:29 5: CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)

2017.07.09 20:37:29 5: SW: ?
2017.07.09 20:37:29 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *

2017.07.09 20:37:29 3: CULM868: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2017.07.09 20:37:29 5: SW: X21
2017.07.09 20:37:29 5: SW: T01
2017.07.09 20:37:29 5: CUL/RAW (ReadAnswer): 0000

2017.07.09 20:37:29 5: GOT CUL fhtid: 0000
2017.07.09 20:37:29 2: Setting CULM868 fhtid from 0000 to 3214
2017.07.09 20:37:29 5: SW: T013214
2017.07.09 20:37:29 1: /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00 reappeared (CULM868)
2017.07.09 20:37:29 5: SW: V
2017.07.09 20:37:29 5: CULM868 sending *V
2017.07.09 20:37:29 5: SW: *V
2017.07.09 20:37:29 5: CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)

2017.07.09 20:37:29 5: SW: ?
2017.07.09 20:37:29 5: CULM868 sending *?
2017.07.09 20:37:29 5: SW: *?
2017.07.09 20:37:29 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z

2017.07.09 20:37:29 3: CULM433: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.07.09 20:37:29 5: SW: X21
2017.07.09 20:37:29 5: CULM868 sending *X21
2017.07.09 20:37:29 5: SW: *X21
2017.07.09 20:37:29 5: SW: T01
2017.07.09 20:37:29 5: CULM868 sending *T01
2017.07.09 20:37:29 5: SW: *T01
2017.07.09 20:37:29 5: CUL/RAW (ReadAnswer): 3214

2017.07.09 20:37:29 5: GOT CUL fhtid: 3214
2017.07.09 20:37:29 2: Setting CULM433 fhtid from 3214 to 3434
2017.07.09 20:37:29 5: SW: T013434
2017.07.09 20:37:29 5: CULM868 sending *T013434
2017.07.09 20:37:29 5: SW: *T013434
2017.07.09 20:37:29 1: FHEM:DEVIO:CULM868_STACK:9600 reappeared (CULM433)


Ich habe nochmals
get CULM868 raw C99
get CULM433 raw C99
get CULM868 raw *C99

Gruß Arnd



Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 Juli 2017, 11:44:48
Zitat von: RaspiLED am 09 Juli 2017, 20:35:50
Meinst Du die Firmware ist buggy drauf?
Da IT bei mir funktioniert, gehe ich jetzt erstmal nicht davon aus, dass es an der Firmware liegt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 10 Juli 2017, 14:33:19
Hi,
Nein ich sage nicht, dass die Firmware ein Problem hat! Sondern frage, ob evtl. schon mal jemand a) ein ähnliches Problem hatte
b) was mit den ständigen Reconnects anfangen kann
c) ein erneutes flashen etwas bringen kann oder
d) andere Ideen hat?
Zusätzlich würde ich mich über Vergleichswerte C99 eines Maple433 freuen!
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 10 Juli 2017, 22:05:06
Zitat von: RaspiLED am 10 Juli 2017, 14:33:19
Nein ich sage nicht, dass die Firmware ein Problem hat! Sondern frage, ob evtl. schon mal jemand a) ein ähnliches Problem hatte
An der Firmware liegt es nicht. Ich prüfe die Geräte, bevor sie veräußert werden. Meine einzige ELRO-Funksteckdose reagiert.

Zitatb) was mit den ständigen Reconnects anfangen kann
Windows? Antwort #391

Zitatc) ein erneutes flashen etwas bringen kann
Es ist nicht auszuschließen ...
## Changelog:
#### 1.25.00
- Improve hardware autodetection


Zitatd) andere Ideen hat?
Hast Du die fhem.save nach "Leichen" durchforstet?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 Juli 2017, 22:09:19
Hier die Antwort eines 868 und eines 433 Maples:
2017.07.10 21:57:57 5: SW: C99
2017.07.10 21:57:57 5: CUL/RAW (ReadAnswer): 0D2E2D07D3913D04
320000060021656A
57C43023B9000700
18146C070090876B
F85611EF2B161F41
00597F3F88310B00

2017.07.10 21:58:07 5: SW: *C99
2017.07.10 21:58:07 5: CUL/RAW (ReadAnswer): *0D2E2D07D3913D04
*320000060010B071
*57C43023B9000700
*18146C070090876B
*F85611EF2C121F41
*00597F1F88310B00
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: trebron106 am 11 Juli 2017, 16:33:16
Hallo,

ich habe die Version 1.25.00 installiert und folgenden Fehler gefunden,



V 1.25.00 a-culfw Build: private build (unknown) MapleCUNx4_83 (F-Band: 868MHz)

pi
0:115200
1:115200

pb0@57600

pi
0:57600
1:115200

ps
pi
0:57600
1:115200


Manueller Reset oder Power off/on

V 1.25.00 a-culfw Build: private build (unknown) MapleCUNx4_83 (F-Band: 868MHz)

pi
0:115200
1:115200



wie man sieht werden nach einem Reset oder Power off/on die Default Werte der Serial Schnittstellen geladen und nicht die gespeicherten Werte.
Bei der Version 1.24.xx hat das speichern der Werte noch funktioniert.

Gruß
Klaus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 Juli 2017, 22:25:16
In der Reihenfolge, in der du Befehle angegeben hast, konnte ich den Fehler nicht nachstellen. Aber ich habe einen Fehler gefunden, bei dem der erste Befehl nach "pb0@57600" nicht ausgeführt wird.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: trebron106 am 12 Juli 2017, 10:37:46
Hallo Telekatz,

bei mir werden die Einstellungen der Baudrate nicht  permanent gespeichert.
Ich habe jetzt einen neuen Maple genommen und bin wie folgt vorgegangen,

- Mit STMFlashLoader Demo zu erst Flash komplett gelöscht
- danach den Bootloader geflasht "maple_mini_boot20.bin" (inkl. Erase Flash)
- Reset
- MapleCUN mit "dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin" geflasht
- Reset
-  IP Parameter eingestellt
- Reset
- Per Putty verbunden


V
V 1.25.00 a-culfw Build: private build (unknown) MapleCUNx4_83 (F-Band: 868MHz)
pi                 <-- Anzeige Baudrate
0:115200
1:115200
pb0@57600  <-- Baudrate setzen
ps                <-- Baudrate speichern
pi                 <-- Anzeige Baudrate
0:57600
1:115200
pi                 <-- Anzeige Baudrate
0:57600
1:115200
pi                 <-- Nach mehrmaliger pi Eingabe oder einer Wartezeit von ca. 10 sec.
0:115200      <-- werden wieder die Default Werte angezeigt und eingestellt
1:115200



Dieses Verhalten kann ich immer wieder nachvollziehen

Gruß
Klaus
 
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 12 Juli 2017, 20:00:39
Diese Reihenfolge der Befehle würde zum gefundenen Fehler passen, da hier "ps" nach "pb0@57600" nicht ausgeführt wird. Bei einem Reboot ist dann wieder die alte Baudrate eingestellt. Aber wirklich erst nach einem Reboot und nicht automatisch nach etwa 10 Sekunden.

Ist dein Maple über USB angeschlossen und läuft bei dir irgend ein Prozess, der die serielle Schnittstelle immer wieder öffnet?

Im Anhang die Version mit dem behobenen Bug zum testen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: trebron106 am 13 Juli 2017, 10:39:48
Hallo Telekatz,

ich habe die Testversion herunter geladen und geflasht.

Mein Testaufbau sieht wie folgt aus,

- MapleCUN per USB an PC, am MapleCUN ist nix angeschlossen
- Serialeverbindung mit PUTTY

hier sind meine Eingaben und die Ausgaben


V
V 1.25.01 a-culfw Build: private build (unknown) MapleCUNx4_00 (F-Band: 868MHz)
pi
0:115200
1:115200
pb0@57600
ps
pi
0:57600
1:115200
30 Sekunden Wartezeit ohne Eingabe
pi
0:115200
1:115200


Danach habe ich den gleichen Test mit einen komplett bestückten MapleCUN gemacht,
das Ergebnis ist das selbe.

Danach MapleCUN per Netzwerk und USB-Netzteil angeschlossen ohne erneute Eingabe der Baudrate
Netzwerkverbindung per Putty Port 2323
hier sind die Ausgaben


V
V 1.25.01 a-culfw Build: private build (unknown) MapleCUNx4_83 (F-Band: 868MHz)
pi
0:57600
1:115200



MapleCUN wieder per USB-Schnittstelle PC angeschlossen
Zugriff über Netzwerk


V
V 1.25.01 a-culfw Build: private build (unknown) MapleCUNx4_83 (F-Band: 868MHz)
pi
0:115200
1:115200


Obwohl keine erneute Eingabe der Baudrate erfolgte und die Schnittstelle nicht geöffnet ist,
verändert sich die Anzeige der Baudrate, wenn die Datenleitungen der USB-Schnittstelle vorhanden sind.


MapleCUN wieder mit USB-Netzteil angeschlossen
Zugriff über Netzwerk


V
V 1.25.01 a-culfw Build: private build (unknown) MapleCUNx4_83 (F-Band: 868MHz)
pi
0:57600
1:115200


Der MapleCUM speichert die Baudrate permanent, aber sobald er über eine USB-Schnittstelle mit Datenleitung verbunden ist,
wird die Einstellung auf Default gesetzt.

Gruß
Klaus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 13 Juli 2017, 12:27:41
Dann läuft auf deinem PC irgend ein Task, der die Serielle Schnittstelle selbstständig öffnet und dabei auch die Baudrate vorgibt. Dass in diesem Fall die gespeicherte Baudrate ignoriert wird ist kein Fehler, sondern Absicht. Das auf die Serielle Schnittstelle zugreifende Programm soll beim öffnen die Baudrate vorgeben könne. So wie es in der CDC USB Klasse vorgesehen ist.

Die Vorgabe der Baudrate über pb und ps ist für den Betrieb über Netzwerk vorgesehen, da dort anders die Baudrate nicht eingestellt werden kann.

Läuft auf deinem PC eventuell eine FHEM instanz, die auf einem CUL oder ähnlichem an den zusätzlichen seriellen Schnittstellen versucht zuzugreifen?



Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: trebron106 am 13 Juli 2017, 12:57:29
Hallo,

auf dem PC (Windows10) ist kein Fhem installiert und es ist und war beim Test  auch kein Programm aktiv, welches auf die Serielle-Schnittstelle zugreift.

Auf dem produktiven System erfolgt der Zugriff nur über das Netzwerk, weshalb mir dieses Verhalten bisher nicht aufgefallen ist.

Gruß
Klaus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 21 Juli 2017, 14:35:10
Ich habe gedacht ich stelle auch mal um auf "stackable"...

Kann es sein dass das "Stack Device" bei mir Qatsch ist und alles auf das erste Device (MAPLECUL868) zeigen muss ?

Zitatdefine MAPLECUL868 CUL 192.168.1.51:2323 4444
attr MAPLECUL868 group Gateways
attr MAPLECUL868 icon cul_868
attr MAPLECUL868 model CUN
attr MAPLECUL868 rfmode SlowRF
attr MAPLECUL868 room TRX
define MAPLECUL868Stack STACKABLE MAPLECUL868
attr MAPLECUL868Stack group Gateways
attr MAPLECUL868Stack room TRX
define MAPLECUL433 CUL FHEM:DEVIO:MAPLECUL868Stack:9600 0000
attr MAPLECUL433 group Gateways
attr MAPLECUL433 hmId 308393
attr MAPLECUL433 icon cul_cul
attr MAPLECUL433 model CUN
attr MAPLECUL433 rfmode SlowRF
attr MAPLECUL433 room TRX
define MAPLECUL868HM CUL FHEM:DEVIO:MAPLECUL868Stack:9600 0000
attr MAPLECUL868HM group Gateways
attr MAPLECUL868HM hmId 308393
attr MAPLECUL868HM icon cul_868
attr MAPLECUL868HM rfmode HomeMatic
attr MAPLECUL868HM room 8.00_Zentral,TRX



Leider kann ich die Frequenz von "MAPLECUL868HM" nicht auf 868 MHz stellen für Homematic:
ZitatInternals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz*
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        FHEM:DEVIO:MAPLECUL868Stack:9600 0000
   DeviceName FHEM:DEVIO:MAPLECUL868Stack:9600
   FD         68
   FHTID      0000
   IODev      MAPLECUL868Stack
   IODevPort  9600
   IODevRxBuffer
   IOReadFn   STACKABLE_IOReadFn
   MAPLECUL868HM_MSGCNT 13
   MAPLECUL868HM_TIME 2017-07-21 12:21:20
   NAME       MAPLECUL868HM
   NR         440
   PARTIAL
   RAWMSG     OFF
   RSSI       -104
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_8F (F-Band: 433MHz)
   initString X21
Ar
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-07-21 12:23:51   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2017-07-21 12:13:09   cmds             b C F i A Z N E G M K L U Y R T V W X f z *
     2017-07-21 12:21:20   state           Initialized
Attributes:
   group      Gateways
   hmId       308393
   icon       cul_868
   rfmode     HomeMatic
   room       8.00_Zentral,TRX
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 21 Juli 2017, 14:51:40
Hi Martin,
Kein Wunder, Dein MAPLECUL868HM und Dein MAPLECUL433 konkurrieren ja auch beide um den ersten Stackplatz.

Du willst noch einen
MAPLECUL433Stack am MAPLECUL433 definieren und den HM dort dranhängen ;-))

Allgemein:
CUL1 -> Stack1 -> CUL2 -> Stack2 -> CUL3 -> Stack3 -> CUL4

Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 21 Juli 2017, 16:19:06
Danke Arndt, dachte das Thema wäre einfacher geworden statt noch komplizierter...  :-X

Nach dem beseitigen der Leichen (VCCU Umfeld) im Keller funktioniert dein Ansatz nun mindestens im Groben bei mir.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 21 Juli 2017, 18:24:07
Hi Martin,
Danke für die Ehre,aber ich glaube das ist Rudis Ansatz, für die ZWave Tests mit dem Maple, den ich nur auch nutzen wollte ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 21 Juli 2017, 22:39:52
Hi,
Zitat von: RaspiLED am 21 Juli 2017, 18:24:07
Danke für die Ehre,aber ich glaube das ist Rudis Ansatz, für die ZWave Tests mit dem Maple, den ich nur auch nutzen wollte ;-)
ich denke die "Zwischenschicht" mit dem Stack ist nötig um das mit allen Protokollen machen zu können ohne das die intern dafür programmiert sind.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 24 Juli 2017, 20:30:18
Mal wieder ein paar Meldungen aus anderem Anlass:
Zitat2017.07.24 18:24:19.705 1: FHEM:DEVIO:MAPLECUL868Stack:9600 disconnected, waiting to reappear (MAPLECUL433)
2017.07.24 18:24:19.706 1: FHEM:DEVIO:MAPLECUL433Stack:9600 disconnected, waiting to reappear (MAPLECUL868HM)
2017.07.24 18:24:19.956 1: FHEM:DEVIO:MAPLECUL868Stack:9600 reappeared (MAPLECUL433)
2017.07.24 18:24:20.066 3: MAPLECUL868HM: Possible commands: bCAZNELYVXfz*
2017.07.24 18:24:20.094 2: Setting MAPLECUL868HM fhtid from ? (T01 is unknown) Use one of b C A Z N E L Y V X f z * to 0000
2017.07.24 18:24:20.099 1: FHEM:DEVIO:MAPLECUL433Stack:9600 reappeared (MAPLECUL868HM)
2017.07.24 18:24:20.110 4: CUL_Parse: MAPLECUL868HM ?  ( T0 1000 0 is u nknown ) Use one of b C A Z N E L Y V X f z *
2017.07.24 18:24:20.112 3: MAPLECUL868HM: Unknown code ? (T010000 is unknown) Use one of b C A Z N E L Y V X f z *, help me!
2017.07.24 18:24:20.371 4: CUL_Parse: MAPLECUL868HM A 0E 2C 8002 2F0E17 308393 010100003428 -54
2017.07.24 18:24:20.372 4: CUL_Parse: MAPLECUL868HM A 0B 53 8440 2CC963 308393 4136FC -76
2017.07.24 18:24:20.395 1: FHEM:DEVIO:MAPLECUL868Stack:9600 disconnected, waiting to reappear (MAPLECUL433)
2017.07.24 18:24:20.395 1: FHEM:DEVIO:MAPLECUL433Stack:9600 disconnected, waiting to reappear (MAPLECUL868HM)
2017.07.24 18:24:20.649 1: FHEM:DEVIO:MAPLECUL868Stack:9600 reappeared (MAPLECUL433)
2017.07.24 18:24:20.759 3: MAPLECUL868HM: Possible commands: bCAZNELYVXfz*
2017.07.24 18:24:20.787 2: Setting MAPLECUL868HM fhtid from ? (T01 is unknown) Use one of b C A Z N E L Y V X f z * to 0000
2017.07.24 18:24:20.792 1: FHEM:DEVIO:MAPLECUL433Stack:9600 reappeared (MAPLECUL868HM)
2017.07.24 18:24:20.795 4: CUL_Parse: MAPLECUL868HM ?  ( T0 1000 0 is u nknown ) Use one of b C A Z N E L Y V X f z *
2017.07.24 18:24:20.797 3: MAPLECUL868HM: Unknown code ? (T010000 is unknown) Use one of b C A Z N E L Y V X f z *, help me!
2017.07.24 18:24:20.906 4: CUL_Parse: MAPLECUL868HM A 0B 55 8440 2CC963 308393 4136FC -76
2017.07.24 18:24:20.930 1: FHEM:DEVIO:MAPLECUL868Stack:9600 disconnected, waiting to reappear (MAPLECUL433)
2017.07.24 18:24:20.931 1: FHEM:DEVIO:MAPLECUL433Stack:9600 disconnected, waiting to reappear (MAPLECUL868HM)
2017.07.24 18:24:21.185 1: FHEM:DEVIO:MAPLECUL868Stack:9600 reappeared (MAPLECUL433)
2017.07.24 18:24:21.295 3: MAPLECUL868HM: Possible commands: bCAZNELYVXfz*
2017.07.24 18:24:21.322 2: Setting MAPLECUL868HM fhtid from ? (T01 is unknown) Use one of b C A Z N E L Y V X f z * to 0000
2017.07.24 18:24:21.327 1: FHEM:DEVIO:MAPLECUL433Stack:9600 reappeared (MAPLECUL868HM)
2017.07.24 18:24:21.331 4: CUL_Parse: MAPLECUL868HM ?  ( T0 1000 0 is u nknown ) Use one of b C A Z N E L Y V X f z *
2017.07.24 18:24:21.332 3: MAPLECUL868HM: Unknown code ? (T010000 is unknown) Use one of b C A Z N E L Y V X f z *, help me!

Die aktuelle Config (ist daran noch etwas falsch?):
Zitatdefine MAPLECUL868 CUL 192.168.1.51:2323 4444
attr MAPLECUL868 group Gateways
attr MAPLECUL868 icon cul_868
attr MAPLECUL868 model CUN
attr MAPLECUL868 rfmode SlowRF
attr MAPLECUL868 room TRX
define MAPLECUL868Stack STACKABLE MAPLECUL868
attr MAPLECUL868Stack room TRX
define MAPLECUL433 CUL FHEM:DEVIO:MAPLECUL868Stack:9600 0000
attr MAPLECUL433 group Gateways
attr MAPLECUL433 hmId 308393
attr MAPLECUL433 icon cul_cul
attr MAPLECUL433 model CUN
attr MAPLECUL433 rfmode HomeMatic
attr MAPLECUL433 room TRX
define MAPLECUL433Stack STACKABLE MAPLECUL433
attr MAPLECUL433Stack room TRX
define MAPLECUL868HM CUL FHEM:DEVIO:MAPLECUL433Stack:9600 0000
attr MAPLECUL868HM group Gateways
attr MAPLECUL868HM hmId 308393
attr MAPLECUL868HM icon cul_868
attr MAPLECUL868HM rfmode HomeMatic
attr MAPLECUL868HM room 8.00_Zentral,TRX
attr MAPLECUL868HM verbose 4

define VCCU CUL_HM 308393
attr VCCU IODev MAPLECUL868HM
attr VCCU IOList MAPLECUL868HM, MCULGARAGE868HM
attr VCCU IOgrp vccu
attr VCCU expert 2_raw
attr VCCU hmKey 01:babc35436f58f5a34fe20214a8516396
attr VCCU model CCU-FHEM
attr VCCU room 8.00_Zentral,TRX
attr VCCU subType virtual
attr VCCU webCmd virtual:update

PS: Habe das Wiki mal wieder etwas verbessert...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 24 Juli 2017, 20:59:10
Hi,
ich denke Deine Config ist richtig. Ich sehe bei mir auch viele Reconnects und auf meine Fragen oben gab es ja auch noch keine antworten. Es könnte aber wirklich an der stackable vs stackable_cc config liegen.
Kannst Du in doppelter Hardware einen Kreuzvergleich durchführen?
Was bräuchte Rudi als Infos für die Überprüfung des stackable codes?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: coolheizer am 27 Juli 2017, 17:06:36
Ich komme einfach nicht weiter,
nach ewigen testen und hier lesen habe ich es endlich geschafft den MapleCUN zu flashen (Win 10, 64bit).

Die maple_mini_boot20.bin habe ich mit Flash loader demonstrator aufgespielt.

Die MapleCUNx4_W5100_BL.bin habe ich mit dfu-util mit dem Befehl dfu-util -d 1eaf:0003 -a 1 -D ./MapleCUNx4_W5100_BL.bin

eingespielt, auch bei mir kam eine Fehlermeldung bei 96%, lt den Aussagen von hier scheint das aber "normal" zu sein.

Angeschlossen ist bisher erst ein CC1101 868Hz, es soll noch ein 433 Modul sowie das W5100 Ethernet Modul hinzu kommen.

Mein jetziges Problem:

Wie bekomme ich den MapleCUN in Fhem angelegt?
define CULMGrau868 CUL /dev/serial/by-id/usb-STM32_MapleCUL_6bfbb14f-if00@38400 1432
attr CULMGrau868 group Gateways
attr CULMGrau868 icon cul_868
attr CULMGrau868 model CUN
attr CULMGrau868 rfmode SlowRF

define CULMGrau868Stack STACKABLE CULMGrau868

define CULMGrau433 CUL FHEM:DEVIO:CULMGrau868Stack:9600 0000
attr CULMGrau433 group Gateways
attr CULMGrau433 icon cul_cul
attr CULMGrau433 model CUN
attr CULMGrau433 rfmode SlowRF



Mit welchen Befehl bekomme ich in der Konsole die richtige Bezeichnung des MapleCUL angezeigt um damit in Fhem das Devise anlegen zu können? "/dev/serial/by-id/usb-STM32_MapleCUL_6bfbb14f-if00" ist aus der Anleitung und nicht von meinem MapleCUN.

Fhem läuft dabei auf einem Raspberry pi3, das 868 Modul soll HM bedienen, das 433 Modul IT.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Juli 2017, 17:10:43
- einloggen
- "cd /dev/serial/by-id/"
- "ls -la"
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 27 Juli 2017, 17:40:36
Hi,
Du brauchst solange Du nur einen 868er auf dem ersten Platz hast keinen Stackable und keine weitere CUL Definition und natürlich den rfmode des ersten CULs anders setzen ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: coolheizer am 27 Juli 2017, 18:04:42
Ui das ging fix.

pi@raspberrypi:~ $ cd /dev/serial/by-id/
-bash: cd: /dev/serial/by-id/: No such file or directory


Der Maple scheint nicht erkannt zu werden? wird noch irgend ein Treiber oder sowas benötigt?

Stecke ich den funktionierenden Selbstbau CUL mit an:

pi@raspberrypi:~ $ cd /dev/serial/by-id/
pi@raspberrypi:/dev/serial/by-id $ ls -la
total 0
drwxr-xr-x 2 root root 60 Jul 27 17:48 .
drwxr-xr-x 4 root root 80 Jul 27 17:48 ..
lrwxrwxrwx 1 root root 13 Jul 27 17:48 usb-FTDI_FT232R_USB_UART_AL033A6C-if00-port0 -> ../../ttyUSB0


dieser wird richtig erkannt.

Ich habe dann nochmal die MapleCUNx4_W5100_BL.bin , mit win 10 geflasht, diesmal nicht mit der 64bit version, dann läuft es durch und bleibt nicht bei 96% hängen:

D:\Raspberry Pi\FHEM\MapleCUN\Arduino_STM32-master\tools\win>dfu-util -d 1eaf:0003 -a 1 -D ./MapleCUNx4_W5100_BL.bin
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1315
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!

D:\Raspberry Pi\FHEM\MapleCUN\Arduino_STM32-master\tools\win>


Der Pfad kann auch danach nicht gefunden werden (cd /dev/serial/by-id/)

Was nun?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Juli 2017, 18:08:44
"lsusb" zeigt dir überigens alle angeschlossenen USB Geräte.
"tail -f  /var/log/syslog" starten und dann einstecken und du siehst was dabei passiert.

https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: coolheizer am 27 Juli 2017, 18:25:49
pi@raspberrypi:/dev/serial/by-id $ lsusb
Bus 001 Device 006: ID 1eaf:0003
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


"tail -f  /var/log/syslog" :

Jul 27 18:21:15 raspberrypi kernel: [   93.637389] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
Jul 27 18:21:15 raspberrypi kernel: [   93.770026] usb 1-1.2: New USB device found, idVendor=1eaf, idProduct=0003
Jul 27 18:21:15 raspberrypi kernel: [   93.770041] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 27 18:21:15 raspberrypi kernel: [   93.770049] usb 1-1.2: Product: Maple 003
Jul 27 18:21:15 raspberrypi kernel: [   93.770056] usb 1-1.2: Manufacturer: Leaf Labs
Jul 27 18:21:15 raspberrypi kernel: [   93.770064] usb 1-1.2: SerialNumber: LLM 003




Und nun?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 27 Juli 2017, 18:27:40
Zitat von: coolheizer am 27 Juli 2017, 18:04:42

Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000"

Du hast die Firmware an die falsche Startadresse geflasht.

Das ist das richtige Kommando:
dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: coolheizer am 27 Juli 2017, 19:08:27
pi@raspberrypi:/dev/serial/by-id $ ls -la
total 0
drwxr-xr-x 2 root root 100 Jul 27 18:52 .
drwxr-xr-x 4 root root  80 Jul 27 18:52 ..
lrwxrwxrwx 1 root root  13 Jul 27 18:52 usb-STM32_MapleCUL_2788282f-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root  13 Jul 27 18:52 usb-STM32_MapleCUL_2788282f-if02 -> ../../ttyACM1
lrwxrwxrwx 1 root root  13 Jul 27 18:52 usb-STM32_MapleCUL_2788282f-if04 -> ../../ttyACM2


Danke euch allen für die super schnelle Hilfe :

dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin

Das war der richtige Tipp, jetzt mal schauen ob ich den Maple richtig in Fhem einbinden kann
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: coolheizer am 27 Juli 2017, 22:43:21
Da das ganze in Fhem mit dem 868MHz Modul super funktioniert wollte ich nun das 433MHz modul verlöten.

Leider habe ich anscheinend ein Falsches Modul erwischt?

Lt. Schaltplan von der 1 Seite kann ich für dieses Modul https://de.aliexpress.com/item/HC-11-433MHz-wireless-RF-serial-UART-module-CC1101-5V-3V-AT-command-HC11/2035515576.html?spm=a2g0s.9042311.0.0.oDIaF3 (https://de.aliexpress.com/item/HC-11-433MHz-wireless-RF-serial-UART-module-CC1101-5V-3V-AT-command-HC11/2035515576.html?spm=a2g0s.9042311.0.0.oDIaF3) keinen Anschluss finden, war das ein Griff ins Klo, oder lässt sich damit doch etwas machen?


Ps. lässt sich das blinken der Led abschalten?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 28 Juli 2017, 08:14:25

Zitat von: coolheizer am 27 Juli 2017, 22:43:21
Leider habe ich anscheinend ein Falsches Modul erwischt?

Lt. Schaltplan von der 1 Seite kann ich für dieses Modul https://de.aliexpress.com/item/HC-11-433MHz-wireless-RF-serial-UART-module-CC1101-5V-3V-AT-command-HC11/2035515576.html?spm=a2g0s.9042311.0.0.oDIaF3 (https://de.aliexpress.com/item/HC-11-433MHz-wireless-RF-serial-UART-module-CC1101-5V-3V-AT-command-HC11/2035515576.html?spm=a2g0s.9042311.0.0.oDIaF3) keinen Anschluss finden, war das ein Griff ins Klo, oder lässt sich damit doch etwas machen?
Das war ein Griff ins Klo, das ist eine serielle Schnittstelle quasi über 868 MHz.

Zitat von: coolheizer am 27 Juli 2017, 22:43:21
Lässt sich das blinken der LED abschalten?
Ja, siehe hier (http://culfw.de/commandref#cmd_l).

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: coolheizer am 28 Juli 2017, 08:51:54
Super danke dir, ein "set MapleCUL868 led 00" hat nun endlich das nerfige blinken ausgeschaltet  :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Juli 2017, 15:38:09
Zitat von: RaspiLED am 24 Juli 2017, 20:59:10
ich denke Deine Config ist richtig. Ich sehe bei mir auch viele Reconnects und auf meine Fragen oben gab es ja auch noch keine antworten. Es könnte aber wirklich an der stackable vs stackable_cc config liegen.

Da ich im Moment ca. "gar keine Zeit" habe werde ich wohl wieder zurück auf stackable_cc gehen und auch das Wiki so anpassen.
Da wir das selbe Problem haben dürfte das ganze als reproduzierbar gelten...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Goggo16 am 29 Juli 2017, 19:12:07
Hi,

muss jetzt erst mal was loswerden. Hut ab vor dem, was Ihr hier leistet.

Bin als Anfaenger fuer FHEM und CUL hier in das Forum wie in das kalte Wasser reingesprungen und mir hab mit dann gleich mal von Ranseyer einen mapleCUN-x4 geangelt. Die Spec klang sehr einleuchtend. Bin aber noch nicht sicher, ob ich mir damit ne Segelyacht angelacht habe anstatt erst mal mit nem kleinen Schlauchboot (nanoCUL oder so) erste Gehversuche zu machen.

Hab die 34 Seiten des Threads und so manche CommandRef mal grob durchgearbeitet. Da geht ja maechtig viel. Aber verstehen muss man es auch irgendwie.

Den mapleCUN-x4 hab ich schon am funktionieren (mit STACKABLE_CC, aber ohne die Stack-CUNs). Die vier CUNs zeigen alle "Initialized".

Frage: Sind dann alle vier CUNs sozusagen am Leben? (Ich frag nur, weil auf den letzten Seiten von Problemen mit STACKABLE vs.  STACKABLE_CC die Rede war.)

Super war, dass ohne viel weiteres Zutun meine Energiesensoren (z.B. ein EM1000S) im FHEMWEB schon richtige Plots liefern. Danach hatte ich seit vielen Jahren immer mal wieder gesucht.

Als naechstes will ich jetzt mal die anderen CUNs dazu bringen, die Arbeit von einem 433er TX/RX-Set (RPI mit pilight) zu übernehmen. Das sind 2x Trust/Intertechno Funkdimmer, ein paar alte RS200 Funkschalter. Neu dazu kommen noch ein paar Dimmer und Schalter von Kopp.

Also schon mal vielen Dank fuer die tolle Arbeit.

LG, Goggo

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 03 August 2017, 08:05:34
Zitat von: PeMue am 08 Juli 2017, 16:12:21
... hat schon jemand mal die Stromaufnahme eines 4-fach mapleCUNs gemessen?
Ein MySensors serielles Gateway braucht (mit 2 LEDs dauerhaft an) 43 .. 45 mA.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 August 2017, 20:02:14
Hallo zusammen,

ich würde mal so mit meiner Platine ins Rennen gehen (siehe Anhang). Wenn jemand noch mal drüberschauen mag, sehr gerne  ;)

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 August 2017, 21:25:55
Ich gehe mal davon aus, dass du überlegt hast wie das LAN Modul zu dem Schraubloch passt... Viel mehr fällt mir nicht ein, aus dem Ausland.

Ps: Und die STM32 Beschallung hast du hoffentlich getestet oder extrem recherchiert...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 10 August 2017, 21:16:59
Hi,

habe nun meinen Maple mit dem kaputten USB Anschluss ausgetauscht.
Den neuen auch auf anhieb geflasht bekommen.

Nun wollte ich auf dem Stackable_CC die Sendeleistung erhöhen, bekomme da aber als Antwort:
set mapleCUL868_2 raw x09
2017-08-10 21:12:49 STACKABLE_CC mapleCUL868_2 raw x09
2017-08-10 21:12:49 STACKABLE_CC mapleCUL868_2 UNKNOWNCODE ? (x09 is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z

Beim nicht Stackable 433 bekomme ich im Log:
set mapleCUL433_2 raw x09
2017-08-10 21:15:39 CUL mapleCUL433_2 raw x09

Warum geht das beim Stackable_CC nicht?
Gibts ne möglichkeit?


Oh je,

jetzt wird der Stackable_CC nur noch als disconnected angezeigt.
Initialisierung sieht so aus:
2017.08.10 21:46:35 3: Setting mapleCUL433_2 serial parameters to 38400,8,N,1
2017.08.10 21:46:35 3: mapleCUL433_2: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz
2017.08.10 21:46:35 1: /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 reappeared (mapleCUL433_2)
2017.08.10 21:46:35 3: mapleCUL868_2: Unknown code  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z, help me!
2017.08.10 21:46:38 3: mapleCUL868_2: Unknown code  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z, help me!
2017.08.10 21:46:41 3: mapleCUL868_2: Unknown code  (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z, help me!

Woran kann das denn liegen? Habe sogar nochmal neu geflashed. Keine Änderung.

Gruß,
Stefan

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 10 August 2017, 21:51:04
Hallo,

Zitat von: Ranseyer am 09 August 2017, 21:25:55
Ich gehe mal davon aus, dass du überlegt hast wie das LAN Modul zu dem Schraubloch passt ... Viel mehr fällt mir nicht ein, aus dem Ausland.
das habe ich noch mal im Schaltplan beschrieben, im Prinzip muss das 43 Mhz Modul gesockelt werden, denn die anderen Module haben kein Loch bzw. das MySensors Modul ist zu noch, um es zu sockeln.

Zitat von: Ranseyer am 09 August 2017, 21:25:55
PS: Und die STM32 Beschallung hast du hoffentlich getestet oder extrem recherchiert...
Nein, ich habe 1:1 die MapleMini Beschaltung verwendet (bis auf die Spannungsregler).

Schaltplan bzw. Layout folgt, sobald ich wieder einen vernünftigen Internetzugang habe.

Gruß PeMue

Edit: Hier https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078 habe ich die aktuellen Daten angehängt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 11 August 2017, 00:11:22
Hi,

habe nun nochmal resetted und auch neu geflashed.
Der MapleCUL verhält sich seltsam.

Bekomme nun wieder beide initialized, also den haupt und den stackable aber die frequenzen stimmen nicht.
Beim Versuch diese zu setzen bekomme ich:

2017.08.11 00:06:24 3: Setting mapleCUL433_2 serial parameters to 38400,8,N,1
2017.08.11 00:06:24 3: mapleCUL433_2: Possible commands: BbCFiAZNEkGMKLUYRTVWXOeflptxz
2017.08.11 00:06:24 2: Setting mapleCUL433_2 fhtid from ? (1 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f l p t x z to 4444
2017.08.11 00:06:24 1: /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 reappeared (mapleCUL433_2)
2017.08.11 00:06:26 3: mapleCUL433_2: Unknown code ? (4 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f l p t x z, help me!
2017.08.11 00:06:26 3: mapleCUL433_2: Unknown code 4444, help me!
2017.08.11 00:06:32 3: sduino_cc1101: Unknown code u6300555555554, help me!
2017.08.11 00:06:38 3: mapleCUL433_2: Unknown code ? (444 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f l p t x z, help me!
2017.08.11 00:06:44 3: sduino_cc1101: Unknown code u63000000000000000000000000000, help me!
2017.08.11 00:06:59 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2017.08.11 00:06:59 3: mapleCUL433_2: Unknown code ? (7DD739W1171 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f l p t x z, help me!
2017.08.11 00:06:59 3: mapleCUL433_2: Unknown code ? (1 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f l p t x z, help me!
2017.08.11 00:06:59 3: mapleCUL433_2: Unknown code ? (4 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f l p t x z, help me!
2017.08.11 00:07:18 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2017.08.11 00:07:18 3: mapleCUL433_2: Unknown code ? (7DD739X21 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f l p t x z, help me!

Hat jemand eine Idee was das sein könnte? Falsche Baudrate?
Zur Zeit ist er so im FEHM definiert:
DEF   /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00@38400 4444

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 August 2017, 00:20:33
Die Baudrate ist egal.

Zeig mal ein list von allen CULs.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 11 August 2017, 00:38:46
Habe eben nochmal ne ältere FW geflasht ohne unterschied.

List vom CUL ist (ist jetzt nur der Haupt CUL nicht der Stackable. Habe ich zum testen gelöscht):

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00@38400 4444
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00@38400
   FD         179
   FHTID      4444
   NAME       mapleCUL433_2
   NEXT_OPEN  1502404483
   NR         914
   PARTIAL
   RAWMSG     ? (7DD7C0D is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_00 (F-Band: 433MHz)
   initString X21
   mapleCUL433_2_MSGCNT 16
   mapleCUL433_2_TIME 2017-08-11 00:35:47
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-08-11 00:34:45   ccconf          freq:5872.941MHz bWidth:67KHz rAmpl:27dB sens:8dB
     2017-08-11 00:35:27   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
     2017-08-10 23:58:19   credit10ms      1876
     2017-08-11 00:35:47   state           Initialized
     2017-08-11 00:25:16   uptime          No answer
     2017-08-11 00:17:46   version         No answer
Attributes:
   room       Devices


Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 11 August 2017, 07:54:33
Hi, also probiere doch mal resets:
set mapleCUL433_2 raw e
set mapleCUL433_2 raw *e
Und danach verbose hochsetzen, damit wir verstehen warum Du ständig was empfängst, was nicht richtig verarbeitet wird.
Hast Du evtl. ein Störfeuer irgendwo? Fernbedienung mit eingeklemmter Taste oder Device mit leerer Batterie?
Gruß Arnd



Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 11 August 2017, 09:19:51
Hi Arnd,

danke.
set mapleCUL433_2 raw e
das hatte ich schon probiert.
Mit
set mapleCUL433_2 raw *e
noch nicht.
Ich werde das heute abend machen.

Warum denkst du ich empfange ständig etwas?
Ein 2ter Maple CUL mit nur 433MHZ hat keine Problem.
Auch erkenne ich an meinen anderen CULs kein seltsamen empfänge.

Auch habe ich an dem problematischen mit den 2 CC1101 zur Zeit nichtmal Antennen dran.

Du hast schon gesehen:
     2017-08-11 00:34:45   ccconf          freq:5872.941MHz bWidth:67KHz rAmpl:27dB sens:8dB

Ich kann die Frequenz einfach nicht richtig setzen.
Der CUL zeigt da irgendetwas an.

Danke und Gruß,
Stefan
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 11 August 2017, 09:58:49
Okay ohne Antennen erklärt es das verhalten vielleicht ;-) Ich wette der empfängt nichts klar, aber das Grundrauschen aus der Elektronik versucht er dann zu verstärken. Kennt jemand das Verhalten eines cc1101 ohne Antennen in der Nähe eines RasPi als Störquelle? Zusätzlich wie verhält sich die Firmware bei ständigen Fehlpaketen? Hängt die sich auf oder resettet oder macht die normal weiter?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 11 August 2017, 10:01:18
Hi,
bzgl der merkwürdigen Freq: Ich habe bei China cc1101 868MHz das gleiche Problem hier, wenn ich Sie mit 3,3V an einem Widerstands Spannungsteiler im nanoCUL betreiben will. Bei 433er habe ich soetwas noch nicht beobachtet.
Welches Modul nutzt Du genau? Ich suche gleich mal Bilder von meinen ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 August 2017, 10:55:37
Zitat von: stefanru am 11 August 2017, 00:38:46

   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_00 (F-Band: 433MHz)

Bei deinem Maple wird kein CC1101 erkannt. Das sieht man an der Zahl hinter "MapleCUNx4_"
Ist bei deinem Maple CC0 unbelegt? Wenn ja, solltest du erst mal auf die aktuelle Version updaten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 11 August 2017, 11:24:21
Ok, ich update heute abend wieder und schicke nochmal die List.

Nein das ist die 2 fach platine.
Hatte sie schon laufen. Habe den Maple nochmal getauscht weil beim alten die USB Buchse defekt war.
Seit dem bekomme ich die frequenzen nicht gesetzt weder für CC0 noch für CC1.
CC0 ist 433 und CC1 ist 868.

Wie gesagt es ging mit dem alten maple auf der platine.

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 11 August 2017, 11:38:20
Wenn Lötstellen schlecht sind eher beim Cc1101. Aber miss doch trotzdem mal die Verbindungen und im speziellen Kurzschluss an den Stamps...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 11 August 2017, 22:43:40
Hi,

bin am Ende mit meinem Latein.
Hoffe jemand hier hat noch ne Idee.
Habe die kleine Platine https://forum.fhem.de/index.php/topic,71571.msg630884.html#msg630884
Auf dieser war vorher ein Maple mit den CC1101 wie jetzt auch.
Das ganze ging wunderbar.
Den Maple habe ich wieder runter gelötet weil der USB Anschluss nicht einwandfrei war. Ich habe es zwar angeschlossen bekommen. Aber eine saubere Lösung war es nicht.

Dann habe ich einen neuen Maple eingelötet. Die CC1101 blieben wie gehabt.
Habe nach dem Schaltplan alles durchgemessen. Sieht alles gut aus CC1101 433 ist CC0 und CC1101 868 CC1.
Kurzschlüsse konnte ich keine finden.

Flashen der MapleCUL direkt bzw MapleCUNx4_W5500_BL.bin über bootloader geht ohne probleme.
Flashen der MapleCUNx4_W5100_BL.bin geht auch. Danach bleibt die LED aber nach dem Bootloader blinken aus. Der Maple wird auch nicht erkannt?

Nun ich habe mit der MapleCUNx4_W5500_BL.bin alle tips hier befolgt.
z.B. set mapleCUL433_2 raw *e

Nach diesem Befehl wurde er wieder neu erkannt und der Stackabel auch.

2017.08.11 22:24:27 3: set mapleCUL433_2 raw *e
2017.08.11 22:24:27 2: autocreate: define STACKABLE_CC_1 STACKABLE_CC mapleCUL433_2
2017.08.11 22:24:27 3: STACKABLE_CC_1: Possible commands: bCFiAZNEGMKLUYRTVWXfz*


Soweit so gut, aber die Frequenzen sind einfach falsch. Ein setzen funktioniert nicht.
Er sagt zwar er würde es tun, macht er aber nicht:

2017.08.11 22:38:37 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2017.08.11 22:38:37 3: mapleCUL433_2: Unknown code ? (84D739W1171 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *, help me!
2017.08.11 22:38:42 3: Setting MDMCFG4 (10) to 3f = 464 KHz
2017.08.11 22:38:49 3: Setting AGCCTRL2 (1B) to 07 / 42 dB
2017.08.11 22:38:54 3: Setting AGCCTRL0 (1D) to 91 / 8 dB


Das selbe danach gleich nochmal diesmal ganz ohne beschwerden des Maples:
2017.08.11 22:40:00 3: Setting FREQ2..0 (0D,0E,0F) to 10 a7 62 = 433.000 MHz
2017.08.11 22:40:05 3: Setting MDMCFG4 (10) to 3f = 464 KHz
2017.08.11 22:40:10 3: Setting AGCCTRL2 (1B) to 07 / 42 dB
2017.08.11 22:40:14 3: Setting AGCCTRL0 (1D) to 91 / 8 dB


Leider bleibt die ccconf:
mapleCUL433_2 ccconf => freq:391.529MHz bWidth:812KHz rAmpl:42dB sens:16dB

Hier nochmal ein List des Devices:
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00@38400 4444
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00@38400
   FD         173
   FHTID      4444
   NAME       mapleCUL433_2
   NR         914
   PARTIAL
   RAWMSG     ? (84D739W1171 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
   STACKED    STACKABLE_CC_1
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.25.01 a-culfw Build: private build (unknown) MapleCUNx4_07 (F-Band: 433MHz)
   initString X21
   mapleCUL433_2_MSGCNT 8
   mapleCUL433_2_TIME 2017-08-11 22:38:37
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-08-11 22:41:01   ccconf          freq:391.529MHz bWidth:812KHz rAmpl:42dB sens:16dB
     2017-08-11 22:22:13   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2017-08-10 23:58:19   credit10ms      1876
     2017-08-11 22:28:49   raw             C10 = 0F / 15
     2017-08-11 22:38:37   state           Initialized
     2017-08-11 00:25:16   uptime          No answer
     2017-08-11 22:23:29   version         V 1.25.01 a-culfw Build: private build (unknown) MapleCUNx4_07 (F-Band: 433MHz)
Attributes:
   room       Devices


Und des Stackables:

Internals:
   CFGFN
   CMDS       bCFiAZNEGMKLUYRTVWXfz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        mapleCUL433_2
   IODev      mapleCUL433_2
   NAME       STACKABLE_CC_1
   NOTIFYDEV  mapleCUL433_2
   NR         1360
   NTFY_ORDER 50-STACKABLE_CC_1
   PARTIAL
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.25.01 a-culfw Build: private build (unknown) MapleCUNx4_07 (F-Band: 433MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-08-11 22:29:45   ccconf          freq:391.529MHz bWidth:812KHz rAmpl:42dB sens:16dB
     2017-08-11 22:24:27   cmds             b C F i A Z N E G M K L U Y R T V W X f z *
     2017-08-11 22:24:27   state           Initialized
Attributes:
   room       STACKABLE_CC


Was kann da denn nur passiert sein?
Das ganze ging ja schonmal. Der Maple wird nicht kaputt sein oder?

Ich hoffe jemand hat noch eine Idee, oder wenigstens einen schimmer was da los ist.

Danke und viele Grüße,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 12 August 2017, 10:19:21
Zitat von: stefanru am 11 August 2017, 22:43:40

   VERSION    V 1.25.01 a-culfw Build: private build (unknown) MapleCUNx4_07 (F-Band: 433MHz)

Du solltest nochmal alle CS Leitungen auf Kurzschlüsse überprüfen. Denn jetzt werden drei CC1101 Module erkannt. Was etwas ungewöhnlich ist bei eine Platine für nur zwei Module.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 12 August 2017, 10:31:47
Hi Telekatz,
Wie ist die Zahl zu lesen? "MapleCUNx4_07"
Binär? 1111=15 (alle 4 bestückt), 0111=07 (nur die ersten drei), 0011=03 (nur die ersten beiden), 0001=01 (nur der erste), 0000=00
Und demnach auch möglich cc1101 zu überspringen? Z.B. 1001=09 (erster und vierter bestückt)???
Gruß Arnd



Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 12 August 2017, 10:56:34
Wie Telekatz schreibt: Kurzschluss suchen, auch Pins 1+3 2+4 usw.

Dann mal am Debug Port lauschen per USB Seriell Wandler und 10 mal booten und  vergleichen. Evtl auch mal die Platine etwas verbiegen und die Debug Ausgabe beobachten.

Gutes Flussmittel drauf und alle Lötstellen sauber nachlegen. Auch der MAPLE oben und unten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 12 August 2017, 12:37:23
Zitat von: RaspiLED am 12 August 2017, 10:31:47
Hi Telekatz,
Wie ist die Zahl zu lesen? "MapleCUNx4_07"
Binär? 1111=15 (alle 4 bestückt), 0111=07 (nur die ersten drei), 0011=03 (nur die ersten beiden), 0001=01 (nur der erste), 0000=00
Und demnach auch möglich cc1101 zu überspringen? Z.B. 1001=09 (erster und vierter bestückt)???
Gruß Arnd

Die ersten vier Bits sind für die Transceiver, das 7. Bit für 1-Wire und das 8. für Netzwerk.
Allerdings werden die unbelegten Transceiver nach der Hardwareerkennung nach hinten verschoben, und die Angabe entspricht dann nicht mehr der tatsächlichen Belegung. Die wirkliche Belegung sieht man nur in der Debugausgabe.
Titel: Selbstbau CUN (mapleCUx): Platine v1.0
Beitrag von: PeMue am 12 August 2017, 15:58:54
Hallo zusammen,

hier kommen die Daten für die mapleCUX Platine.

Beschreibung:
Kern der Platine ist ein diskret aufgebauter MapleMini (um Platz zu sparen).  Die Spannungsversorgung erfolgt entweder mittels eines Schaltreglers (MAX1837) oder eines Linearreglers (MCP1703).
Es können zwei Radios mit 433 bzw. 868 MHz (CC0 und CC3 als SMD) bzw. ein Radio mit 433 MHz (CC1) bestückt werden. Ein diskret aufgebautes MySensors Gateway ist an TX0/RX0 angeschlossen, ein HMUART Modul TX1/RX1. Das Radio an CC2 wurde durch eine 1-wire Busschaltung ersetzt. Die 1-wire Sensoren werden mittels eines 3-pol. Würth SMD Steckers angeschlossen. Optional kann ein LAN Modul (USR-ES1) verbaut werden.
Das Ganze soll in ein Hammond 1593LGY Gehäuse (https://asset.re-in.de/isa/160267/c1/-/de/522654_RB_00_FB/Hand-Gehaeuse-1593lgy-92x66x28mm-Grau.jpg?y=525&align=center) rein (Link ist leider in schwarz und nicht grau) und meinen CUNO V2 ablösen.

Schaltplan:
Siehe Anhang (https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=83346).

Layout:
Siehe Anhang (https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=83347). 10 Leiterplatten sind bestellt und auf dem Weg.

Bilder:
Die ersten Platinen sind da, ich habe mal zwei Bilder eingestellt. Die Höhe passt soweit auch, CC1 sollte gesockelt werden können, so dass wenigstens eine Schraube für die Leiterplatte nutzbar ist.

<Platzhalter> für Aufbauanleitung bzw. Inbetriebnahme.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 12 August 2017, 21:18:33
Hi,

ich dank euch mal wieder herzlich!
Wollte schon fast aufgeben.
Zu messen war nichts, sah alles gut aus.

Habe dann nochmal wie empfohlen den Maple von unten gelötet.
Scheinbar hatte da ein Beinchen durch das entlöten des alten Maple einen Wackler.

Jetzt wird alles richtig erkannt und es kann auch alles gesetzt werden!

Vielen Dank für die Hilfe!

Gruß,
Stefan

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 12 August 2017, 21:28:42
Das freut mich. Wollte gerade per PN aktive Hilfe anbieten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 20 August 2017, 19:18:27
Hallo zusammen,

habe hier https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078 die Daten der Platine aktualisiert (und werde da weiter berichten). Platinen sind im Flieger  :)
@Telekatz: Wenn Du magst, kannst Du diesen Post im Deinem ersten Post verlinken.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 25 August 2017, 16:44:41
Hallo zusammen,

die Post war da mit den Platinen (und der Urlaub ist leider rum  :(). Ich habe hier (https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078) mal ein paar Bilder eingestellt, wie das Ganze aussehen wird.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 04 September 2017, 08:32:59
Hallo zusammen, Ich baue gerade fünf mapleCUx zusammen und rätsel noch welche Spule ich für den NRF24L01+ bestellen sollte. Leider gibt es da keine Angaben in den EAGLE Files. Ist ein SMD Bauteil im VCC Pfad (vermutlich zum entstören).
https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large

Evtl kann mir hier jemand behilflich sein.

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 September 2017, 08:36:18
Das ist keine Spule sondern ein Kondensator:  4.7µ - 47µF
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 04 September 2017, 09:06:48
Zitat von: gloob am 04 September 2017, 08:36:18
Das ist keine Spule sondern ein Kondensator:  4.7µ - 47µF
Kann nicht sein da dann der NRF24L01+ keine Spannung bekommen würde. Zickzacklinien sind Spulen. (VCC Leitung vom Arduino Mini zum NRF24L01+)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 September 2017, 09:14:33
Zitat von: Eistee am 04 September 2017, 09:06:48
Kann nicht sein da dann der NRF24L01+ keine Spannung bekommen würde. Zickzacklinien sind Spulen. (VCC Leitung vom Arduino Mini zum NRF24L01+)

Sorry hatte jetzt nur blind Geraten und die Eagle Files nicht geöffnet. Du meinst sicherlich L1 und nicht C5, oder?
Ich hab ja schon viele Schaltpläne mit NRF24L01 und Atmega gesehen aber noch nie eine Spule am VCC  ???
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 September 2017, 09:59:03
Kondensator wären 0-100uF. Mit PA auch 200 uF. Die hier genannte Drossel bildet mit dem Kondensator einen Tiefpass für die Spannungsversorgung. Also das selbe wie die lustigen Adonis Platinen für den NRF2401.
Schau doch mal bei ebay welche Werte diese haben. Ich habe das nicht im Kopf.

(für den Anfang reicht auch eine Brücke)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 04 September 2017, 12:38:48
Zitat von: Ranseyer am 04 September 2017, 09:59:03Also das selbe wie die lustigen Adonis Platinen für den NRF2401.
Weiss nicht was du damit für eine Platine meinst. Kannst du da mal einen Link zu posten bitte?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 11 September 2017, 22:04:26
Hui, meine Platine (https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078) zeigt erste Reflexe. Und der STM scheint auch der richtige zu sein  ;D ;D ;D
Der Bootloader ist auf jeden Fall mal drauf, jetzt wird weiterbestückt.

@Telekatz: Roger Clark hat wohl bei github etwas umsortiert, der Link in der im ersten Post verlinkten Flashanleitung funktioniert nicht mehr.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 11 September 2017, 22:18:42
Zitat von: Eistee am 04 September 2017, 12:38:48
Weiss nicht was du damit für eine Platine meinst. Kannst du da mal einen Link zu posten bitte?


Spontan auch nicht gefunden. Ca. sowas aber mit Drosselspule in der Zuleitung:
http://www.ebay.de/itm/Steckdosen-Adapterplatten-Platine-Fur-10-Poliges-Nrf24l01-Funk-Transceivmodul-Z-/232319188109?hash=item36174d7c8d:g:CZkAAOSwo4pYHmfL

Nimm doch einfach irgendeine drossel die 50-100mA aushält und die du eh in der Schublade hast. Wenn keine in der Schublade: einfach brücken.
Der genaue Wert ist eher unwichtig.

In die Stromversorgung einen Elko und zuätzlich einen kleinen Keramik Kondensator.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: tuxinator am 20 September 2017, 21:09:03
Ich habe gerade etwas Zeit, mit meinem MapleCUN v 2.0 weiterzumachen und MySensors zu ergänzen .. jetzt hab ich hier meinen Arduino und einen nRF24L01+PA+LNA vor mir liegen. Werden die wirklich beide auf der Oberseite bestückt - Also der nRF irgendwie über den Arduino?

LG,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 23 September 2017, 23:25:44
Hallo,

habe noch  eine Frage zu der Large Platine. Was muss ich denn machen um den Arduino zu flashen. Wenn ich einen USB2TTY am Arduino anschließe klappt das nicht. Vermutlich funkt der Marple da dazwischen.

Ich hoffe ich muss das nicht wieder auseinander löten.

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 24 September 2017, 08:30:03
Zitat von: tuxinator am 20 September 2017, 21:09:03
jetzt hab ich hier meinen Arduino und einen nRF24L01+PA+LNA vor mir liegen. Werden die wirklich beide auf der Oberseite bestückt - Also der nRF irgendwie über den Arduino?
Schau dir bitte dringend den Bestückungsplan an und vergleiche die Pinbelegung bevor du mehrpolige Bauteile einlötest, dann erübrigt sich die Frage.

ZitatLarge Platine. Was muss ich denn machen um den Arduino zu flashen. Wenn ich einen USB2TTY am Arduino anschließe klappt das nicht. Vermutlich funkt der Marple da dazwischen.
Welche Platinenversion hast du denn genau ? 

PS: In diesem Thread geht es um den MAPLE-CUN. Der MAPLE-Cun besteht nur aus einem MAPLE mit Funkmodulen. Somit sind diese Fragen hier wohl etwas OT. Denke hier passt es besser: https://forum.fhem.de/index.php/topic,50990.120.html
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: balki am 24 September 2017, 11:53:10
Guten Morgen  oder besser Mahlzeit 

Ich benutze ja auchn den Maple Cun 

Kann mir jemand sagen was das ist und wie ich es aus den Logfiles raus bekomme ??

myHmUARTLGW: Unknown code A0FA286103A54170000000A88CD0C0040::-93:myHmUARTLGW, help me!



Danke
Gruß
Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stenny73 am 24 September 2017, 12:03:19
Hallo

Hatte vor langer Zeit schon mal angefragt ob schon jemand über die Serielle Schnittstelle einen
Z-Wave Komtroller angebunden hat. Ich würde damit ggf meinen USB Dongle ersetzen wollen sofern
es positive Erfahrungen gibt.

stenny
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 24 September 2017, 12:33:42
Hi,
Zitat von: stenny73 am 24 September 2017, 12:03:19
Hatte vor langer Zeit schon mal angefragt ob schon jemand über die Serielle Schnittstelle einen
Z-Wave Komtroller angebunden hat. Ich würde damit ggf meinen USB Dongle ersetzen wollen sofern
es positive Erfahrungen gibt.
hatte das auch vor, habe es aber bisher aus Zeitmangel nicht umsetzen können. Ich habe mir dazu ein weiteren RazBerry-Modul angeschafft, das liegt aber noch unverdrahtet hier auf dem Tisch rum (ebenso wi ein HM-UART, den ich in dem Chaos aber momentan nicht mal finde...).
Von daher leider keine positive Erfahrung, wäre aber auch einer RM interessiert wenn es dann mal jemand vor mir schafft das in Betrieb zu nehmen.

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stenny73 am 24 September 2017, 12:36:34
Danke erstmal für die schnelle Antwort.
Dann schaue ich mal ob ich zum testen ein Modul bestelle.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 24 September 2017, 12:58:03
Zitat von: stenny73 am 24 September 2017, 12:03:19
Hatte vor langer Zeit schon mal angefragt ob schon jemand über die Serielle Schnittstelle einen
Z-Wave Komtroller angebunden hat. Ich würde damit ggf meinen USB Dongle ersetzen wollen sofern
es positive Erfahrungen gibt.


Ich habe das nicht vor. Aber im Prinzip handelt es sich ja einfach um eine Serielle Verbindung die m.E. transparent per LAN verlängert wird. Würde schon annehmen dass das prinzipiell klappen sollte. (Pegel beachten!)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: A.Harrenberg am 24 September 2017, 15:46:05
Hi,
Zitat von: Ranseyer am 24 September 2017, 12:58:03
Würde schon annehmen dass das prinzipiell klappen sollte. (Pegel beachten!)
oha, das mit dem Pegel hatte ich gar nicht bedacht. Ich geh' davon aus der ST32M hat da 3.3V Pegel, oder?
Muss mal schauen was der Raspi da hat...
Danke für den Hinweis!

Gruß,
Andreas.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 Oktober 2017, 18:11:07
Hallo,

die Platine (https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078) zeigt weitere Grundreflexe: die Firmware ist flashbar. Sprich: der maple Mini funktioniert. Das mit den 97 % war irgendwie bei allen meinen maple Minis der Fall.
dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download d:\3_work\MapleCUNx4_W5500_BL.bin
Jetzt kommt sukzessive die Bestückung der Radios, 1-wire, am Schluss dann das MySensors Gateway.

Gruß PeMue

Edit: Ich habe mal die a-culfw v1.26.01 build 272 (das BIN sagt 271) geflasht, mal sehen, ob diese funktioniert  ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Oktober 2017, 11:30:43
Zitat von: PeMue am 09 Oktober 2017, 18:11:07
Hallo,

die Platine (https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078) zeigt weitere Grundreflexe: die Firmware ist flashbar. Sprich: der maple Mini funktioniert. Das mit den 97 % war irgendwie bei allen meinen maple Minis der Fall.
Jetzt kommt sukzessive die Bestückung der Radios, 1-wire, am Schluss dann das MySensors Gateway.

Gruß PeMue

Edit: Ich habe mal die a-culfw v1.26.01 build 272 (das BIN sagt 271) geflasht, mal sehen, ob diese funktioniert  ;)
Eine Frage vor allem an Telekatz : Wenn ich den dritten und vierten TRX jeweils doppelt verbauen würde, wie würde ich am einfachsten eine der Dupletten abschalten? Einfach VCC auftreten und die restlichen Leitungen trotzdem verbunden lassen? (reicht das aus?)

Gesendet von meinem VTR-L09 mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 15 Oktober 2017, 11:44:53
Bei CSn muss man aber auch noch GDO0 und GDO2 abschalten, da die Default Konfigurationen dafür CLK_XOSC/192 und CHP_RDYn Output sind.
Ich würde es mal mit VCC probieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 15 Oktober 2017, 11:48:15
Time base tolerance and warm up time of the transmitter and receiver (CC1101) (https://e2e.ti.com/support/wireless_connectivity/low_power_rf_tools/f/155/t/284561)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Oktober 2017, 12:17:39
ZitatIch würde es mal mit VCC probieren.

Danke probiere ich. (Ziel: Ich werfe alles unnötige Zeug von meinen mehrfach CUL herunter und baue eine kleine Erweiterungsplatine, da mir RFM69 wichtiger geworden ist...)

ZitatTime base tolerance and warm up time of the transmitter and receiver (CC1101)

Hmm, habe den Zusammenhang nicht so ganz verstanden. Meine Frage wäre ob man einen CC1101 deaktivieren kann wenn er keinen Saft mehr bekommt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 15 Oktober 2017, 12:20:26
Zitat von: Ranseyer am 15 Oktober 2017, 12:17:39Hmm, habe den Zusammenhang nicht so ganz verstanden. Meine Frage wäre ob man einen CC1101 deaktivieren kann wenn er keinen Saft mehr bekommt.

Es ist ein Unterschied ob man den CC1101 nur deaktiviert oder VCC schaltet ... Ist vielleicht in Deinem Anwendungsfall nicht gegeben.
Bei einem Multiplexing würde es wohl eher relevant sein. 

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Oktober 2017, 12:25:41
Hmm, wir werden sehen. Mir geht es nur darum dass er die Kommunikation des zweiten Moduls nicht behindert und "still ist"...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rainman79 am 22 Oktober 2017, 14:16:17
Hallo,
Woran könnte es liegen, das sich beim 4 CUL die Frequenz nicht ändern lässt?
Aufgelötet sind Folgende Module:
                                                            CC0=868MHz    mapleCul1
                                                            CC1=433MHz    mapleCul2 (STACKABLE_CC mapleCul1)
                                                            CC2=868MHz    mapleCul3 (STACKABLE_CC mapleCul2)
                                                            CC3=433MHz    mapleCul4 (STACKABLE_CC mapleCul3)

Eine Abfrage mit "get mapleCUL4 raw C35" gibt mir "mapleCUL4 raw => C35 = 01 /  1" zurück.
Hier mal ein List vom Device:Internals:
   CFGFN
   CMDS       CAZNELYVXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        mapleCUL3
   IODev      mapleCUL3
   NAME       mapleCUL4
   NOTIFYDEV  mapleCUL3
   NR         137
   NTFY_ORDER 50-mapleCUL4
   PARTIAL
   RAWMSG     ? (W1171 is unknown) Use one of C A Z N E L Y V X f z
   STATE      Initialized
   StackLevel 3
   TYPE       STACKABLE_CC
   VERSION    V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) MapleCUNx4_0F (F-Band: 868MHz)
   initString X21
   mapleCUL4_MSGCNT 4
   mapleCUL4_TIME 2017-10-22 14:09:15
   Helper:
     DBLOG:
       cmds:
         DBLogging:
           TIME       1508672004.93723
           VALUE       C A Z N E L Y V X f z
       state:
         DBLogging:
           TIME       1508672004.99603
           VALUE      Initialized
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-10-22 13:33:36   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2017-10-22 13:33:41   cmds             C A Z N E L Y V X f z
     2017-10-22 13:33:45   credit10ms      644
     2017-10-22 13:33:52   fhtbuf          No answer
     2017-10-22 14:05:32   raw             C35 = 01 /  1
     2017-10-22 14:09:15   state           Initialized
Attributes:
   DbLogExclude .*
   group      CUL
   room       Empfang


Und hier ein Auszug aus der Log-File beim versuch die Frequenz zu ändern: 2017-10-22_13:33:52 mapleCUL4 fhtbuf: No answer
2017-10-22_13:49:40 mapleCUL4 raw: C35 = 01 /  1
2017-10-22_14:03:53 mapleCUL4 raw: C35 = 01 /  1
2017-10-22_14:05:32 mapleCUL4 raw: C35 = 01 /  1
2017-10-22_14:09:15 mapleCUL4 freq 433.920
2017-10-22_14:09:15 mapleCUL4 UNKNOWNCODE ? (W0F10 is unknown) Use one of C A Z N E L Y V X f z
2017-10-22_14:09:15 mapleCUL4 UNKNOWNCODE ? (W10b0 is unknown) Use one of C A Z N E L Y V X f z
2017-10-22_14:09:15 mapleCUL4 UNKNOWNCODE ? (W1171 is unknown) Use one of C A Z N E L Y V X f z


Bei allen anderen Funktioniert das Ändern der Parameter.

Gruß Holger
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 22 Oktober 2017, 15:47:12
Weil beim 4. CUL kein SlowRF funktioniert und man deshalb die Frequenz nicht einstellen muss.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rainman79 am 22 Oktober 2017, 15:57:15
Aha, gut, nur ist dort ja ein 433 MHz Modul eingelötet und es wird ein 868 MHz Modul erkannt.

Gruß Holger
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 22 Oktober 2017, 16:06:56
Die Firmware kann nicht erkennen, ob es ein 433 oder 868 MHz Modul ist. Das sind die Defaultwerte, die da angezeigt werden.

Die Frequenz muss man nur bei SlowRF anpassen können. Bei den anderen Protokollen wird automatisch die richtige Frequenz eingestellt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: doman75 am 23 Oktober 2017, 10:32:25
Also macht es keinen Sinn an 4 Stelle ein 433 Modul einzubauen oder?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 23 Oktober 2017, 11:46:26
Nein, es macht es keinen Sinn.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 23 Oktober 2017, 16:30:08
ZitatNein, es macht es keinen Sinn.

Die Frage ist für mich ob man sagen kann wer welches Protokoll auf welcher Frequenz nutzt.

Ich bin für mich davon ausgegangen die einzig sinnvolle Bestückung ist: 868, 433,868,868MHz
Wenn man weiters davon ausgeht Homematic sollte auf jeden Fall gehen und den vierten Steckplatz sollte man auch weniger nutzen als den ersten, dann bliebe ja fast nur übrig:
-868, 433,868,868MHz
-868, 433,868MHz

Oder man muesste den dritten Platz für 433MHz opfern, also:
868, 433, 433, 868
Das finde ich ziemlich uncool wenn man Homematic will und der erste TRX schon durch SlowFR-868 belegt ist...*

PS: Ich habe das zweite 433MHz Modul schon auch auf den vierten Platz verbaut weil mir unklar ist welche Protokolle bei 433MHz heute verfügbar sind, oder welche es künftig sein werden...

Ich fürchte fast, ein Vollausbau schreit nach einer Jumper-Lösung :-(



*Meine unbewiesene Meinung: Die Daten des vierten Transceivers laufen ja in FHEM über mehrere Stufen und intern beim Maple wie ich das verstanden hatte auch. Daher ergibt sich mein Gefühl bevorzugt die ersten zu Nutzen.
Titel: Antw:MapleCUL USB-Stick mit zwei CC1101 Transceivern
Beitrag von: chris1284 am 23 Oktober 2017, 18:12:19
Zitat von: locutus am 17 April 2017, 21:50:12
- GND/3V3/RX/TX am MapleCUL mit einem USB zu TTL Adapter verbinden.
- USB zu TTL Adapter mit dem PC verbinden.
- Taste BOOT am MapleCUL drücken und gerdückt halten.
- Taste RST am MapleCUL drücken.
- Tasten loslassen.
- STM32 Flash loader demonstrator starten.
- COM Port des USB zu TTL Wandlers auswählen, Baud Rate 115200, Parity Even, Echo Disabled, Timeout 1.
- Auf Next drücken.
- Es sollte die Meldung erscheinen: Target is readable. Please click "Next" to proceed.

wie muss denn die led am mapleCUL blinken? wenn ich ihn anstecke blinkt sie vor sich hin, drücke und halte ich boot und drücke dann rst hört sie kurz auf und blink dann wie vorher weiter. eine Verbindung bekomme ich jedoch über den STM32 flash loader demonstartor nicht.

wobei ich gerade sehe das ich eine usb uart-adapter habe....  ::) geht das mit auch?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 23 Oktober 2017, 21:07:05
Zitat von: Ranseyer am 23 Oktober 2017, 16:30:08
Die Frage ist für mich ob man sagen kann wer welches Protokoll auf welcher Frequenz nutzt.

Ich bin für mich davon ausgegangen die einzig sinnvolle Bestückung ist: 868, 433,868,868MHz
Wenn man weiters davon ausgeht Homematic sollte auf jeden Fall gehen und den vierten Steckplatz sollte man auch weniger nutzen als den ersten, dann bliebe ja fast nur übrig:
-868, 433,868,868MHz
-868, 433,868MHz
Neben SlowRF nutzt Intertechno und Somfy 433MHz. Wegen der fehlenden Out Leitung am vierten Steckplatz kann man dort diese Protokolle aber auch nicht verwenden.
Nutzbar am vierten Steckplatz sind Homematic, MAX, RWE, LaCrosse und FastRF (alles 868MHz)

Zitat von: Ranseyer am 23 Oktober 2017, 16:30:08
Oder man muesste den dritten Platz für 433MHz opfern, also:
868, 433, 433, 868
Das finde ich ziemlich uncool wenn man Homematic will und der erste TRX schon durch SlowFR-868 belegt ist...*
Homematic funktioniert am vierten Steckplatz genauso gut oder schlecht wie am ersten. Nennenswerte Laufzeitunterschiede gibt es da nicht.

Meine Empfehlung für 2 x 868MHz und 2 x 433MHz:
-868, 433, 433, 868

Zitat von: chris1284 am 23 Oktober 2017, 18:12:19
wie muss denn die led am mapleCUL blinken? wenn ich ihn anstecke blinkt sie vor sich hin, drücke und halte ich boot und drücke dann rst hört sie kurz auf und blink dann wie vorher weiter. eine Verbindung bekomme ich jedoch über den STM32 flash loader demonstartor nicht.
Da damit der interne Bootloader aktiviert werden soll darf gar nichts blinken.

Zitat von: chris1284 am 23 Oktober 2017, 18:12:19
wobei ich gerade sehe das ich eine usb uart-adapter habe....  ::) geht das mit auch?
So einer auf 9 poligen D-Sub Stecker? Der geht nicht, falscher Pegel.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: chris1284 am 23 Oktober 2017, 21:19:29
Ne usb Uart. Mittlerweile Blink er nur noch und wird usb selbst nicht mehr von fhem erkannt. Kann es sein das ich die fw gelöscht habe durch das drücken Bonn Boot und Rst (hatte auch mal Boot beim einstecken gedrückt gehalten wie beim cul)? Ein usb ttl Adapter ist bestellt  ;D
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 23 Oktober 2017, 22:15:45
Solange er blinkt läuft noch irgend ein Programm.

Blinkt er mit 0,5Hz ist es die a-culfw. Blinkt er schneller, ist es der Maple Bootloader. Dann kann man mit dem dfu-util updaten. Bei einem neuen Maple muss man aber vorher noch den Bootloader updaten:
https://forum.fhem.de/index.php/topic,60458.msg600942.html#msg600942 (https://forum.fhem.de/index.php/topic,60458.msg600942.html#msg600942).
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rainman79 am 24 Oktober 2017, 07:09:34


Zitat von: Telekatz am 23 Oktober 2017, 21:07:05

Meine Empfehlung für 2 x 868MHz und 2 x 433MHz:
-868, 433, 433, 868

Wunderbar, hab meinen nun ungelötet auf 868,433,433,868 nun empfängt der zweite 433 auch. Danke.

Gruß Holger

Gesendet von meinem D6503 mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: doman75 am 24 Oktober 2017, 10:09:47
Ja genau ich habe mal einen von Dir gekauft, der hat 868,433,868,433 und der 4 Platz ist somit nie nutzbar gewesen.

Sehr gut klingt da die Aufteilung von Telekatz mit 868,433,433,868 aber das kann ich nicht ändern.

Grüße
Swen


Zitat von: Ranseyer am 23 Oktober 2017, 16:30:08
Die Frage ist für mich ob man sagen kann wer welches Protokoll auf welcher Frequenz nutzt.

Ich bin für mich davon ausgegangen die einzig sinnvolle Bestückung ist: 868, 433,868,868MHz
Wenn man weiters davon ausgeht Homematic sollte auf jeden Fall gehen und den vierten Steckplatz sollte man auch weniger nutzen als den ersten, dann bliebe ja fast nur übrig:
-868, 433,868,868MHz
-868, 433,868MHz

Oder man muesste den dritten Platz für 433MHz opfern, also:
868, 433, 433, 868
Das finde ich ziemlich uncool wenn man Homematic will und der erste TRX schon durch SlowFR-868 belegt ist...*

PS: Ich habe das zweite 433MHz Modul schon auch auf den vierten Platz verbaut weil mir unklar ist welche Protokolle bei 433MHz heute verfügbar sind, oder welche es künftig sein werden...

Ich fürchte fast, ein Vollausbau schreit nach einer Jumper-Lösung :-(



*Meine unbewiesene Meinung: Die Daten des vierten Transceivers laufen ja in FHEM über mehrere Stufen und intern beim Maple wie ich das verstanden hatte auch. Daher ergibt sich mein Gefühl bevorzugt die ersten zu Nutzen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 24 Oktober 2017, 12:10:59
Siehe PN finden wir ne Lösung.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: chris1284 am 26 Oktober 2017, 17:52:30
Ich brauche da mal Hilfe beim Flashen des MapleCUL von Locutus.
Anbei ein Screenshot der Fehlermeldung sowie die Konfig vom Flashloader und COM-Port (USB-TTL COnverter mit CP2102 Chip).
Ich gehe nach Anleitung (MapleCUL mit TTL Adapter verbinden, An Rechner stecken -> Apdater leuchtet rot durchgängig, Ample blinkt alle 1 Sekunde auf, Boot drücken und halten, rst drücken, beide loslassen -> Maple blinkt dann wieder alle 1 Sekunde, SW starten , konfig chekcen, Next drücken-> Fehlermeldung erscheint) vor, erhalte aber immer die Rückmeldung
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: chris1284 am 26 Oktober 2017, 17:53:11
Ich vollidiot. man darf natürlich rx nicht mit rx und tx nicht mit tx verbinden sondern muss diese kreuzen ::) >:(
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 26 Oktober 2017, 18:18:41
Zitat von: chris1284 am 26 Oktober 2017, 17:52:30
Ich gehe nach Anleitung (MapleCUL mit TTL Adapter verbinden, An Rechner stecken -> Apdater leuchtet rot durchgängig, Ample blinkt alle 1 Sekunde auf, Boot drücken und halten, rst drücken, beide loslassen -> Maple blinkt dann wieder alle 1 Sekunde, SW starten , konfig chekcen, Next drücken-> Fehlermeldung erscheint) vor, erhalte aber immer die Rückmeldung
Der Maple blinkt nicht, wenn der interne Bootloader läuft. Lass mal erst rst und dann Boot los.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: chris1284 am 26 Oktober 2017, 18:22:34
Zitat von: chris1284 am 26 Oktober 2017, 17:53:11
Ich vollidiot. man darf natürlich rx nicht mit rx und tx nicht mit tx verbinden sondern muss diese kreuzen ::) >:(
Danke für deine Mühe, das rx/tx Problem war die Ursache
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 28 Oktober 2017, 19:59:31
Zitat von: Telekatz am 23 Oktober 2017, 21:07:05
Meine Empfehlung für 2 x 868MHz und 2 x 433MHz:
868, 433, 433, 868
Ok, das passt bei meiner Platine. Die hat:
868, 433, 1-wire, 868 MHz. 2x 433 MHz ist nicht vorgesehen, ich frage mich aber auch, wozu man das braucht. Homematic geht über die ELV Raspberry Pi Platine an einer seriellen Schnittstelle.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Lutze53 am 30 Oktober 2017, 00:21:30
Guten Abend,

bin mom dabei wieder mein Server aufzubauen und hab noch von HM die CCU1, aber iwie nimmt die zuviel Platz weg und möchte daher auf andere alternativen wechseln. Jetzt wird mom sehr viel von MapleCUN geschrieben. Hab schon mal im Netz geschaut und versucht bei ALI welche zu finden. Jetzt habe ich habe auf vielen Bildernoch eine grosse Platine gesehen wo die Sendemodule dran sind und der Maple oben drauf, aber iwie finde ich dieses Bauteil nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 30 Oktober 2017, 08:29:34
Ehrlich gesagt hab eich Deine Frage nicht ganz verstanden. Aber du kannst Dir Ali/Ebay "Maple Mini" und  CC1101 Module bestellen. Diese verbindest du selbst. Oder du kannst wenn es einfacher laufen soll eine fertige Platine nehmen: https://wiki.fhem.de/wiki/MapleCUX-Platinen. Solche Platinen bekommst Du bei mir, oder lässt sie eben selbst fertigen.

PS: PeMue schreibt weiter oben von einer Alternative, aber dazu müsstest du feintes SMD löten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Lutze53 am 31 Oktober 2017, 01:55:35
Naja SMD löten ist jetzt nicht so mein Fall, was kostet denn das fertige Modul bei dir ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 31 Oktober 2017, 08:16:00
Zitat von: Lutze53 am 31 Oktober 2017, 01:55:35
Naja SMD löten ist jetzt nicht so mein Fall, was kostet denn das fertige Modul bei dir ?

Ich habe noch einen überzähligen Maple da. Verbaut mit zwei Transceivern. Ca. so: https://forum.fhem.de/index.php/topic,70787.0.html

Rest gerne per PN.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: astro0302 am 31 Oktober 2017, 21:21:11
Scheinbar bin ich zu doof für den MapleCUN Large mit W5500. Der MapleCUN hängt bei mir nicht am Raspi, sondern soll im Dachgeschoss über einen Switch angeschlossen werde!

Ich flashe den MarpleMini über den STM Flash Loader Demonstrator mit dem aktuellsten MapleCUNx4_W5500_BL.bin. Die Übertragung ist lt. STM Flash Loader auch erfolgreich. Wenn ich das Teil bei mir an den Switch hänge, ist das Teil über keine IP meines kleinen DHCP-Bereiches anpingbar. Mein Router gibt leider keine Info aus, welche IP-Adressen er vergibt :-(

In den Kommentaren habe ich gelesen, dass die LED auf dem MapleMini blinken müsste (so wie ich es auch von meinen nanoCUL kenne). Diese blinkt bei mir nicht.

Jemand eine zündende Idee was ich falsch gemacht habe bzw. eine Möglichkeit zur Analyse?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 31 Oktober 2017, 21:28:54
Zitat von: astro0302 am 31 Oktober 2017, 21:21:11
Ich flashe den MarpleMini über den STM Flash Loader Demonstrator mit dem aktuellsten MapleCUNx4_W5500_BL.bin.
Ich bin zwar nicht der Spezialist, aber ich meine, Du brauchst den Bootloader. Telekatz hat im ersten Post eine Anleitung zum Flashen verlinkt, wenn ich richtig bin, geht das so:
- Bootloader mit STM Flasher flashen, danach
- über USB mit anderem Tool MapleCUNx4_W5500_BL.bin flashen.
Falls das nicht funktioniert, kannst Du an der seriellen Schnittstelle "lauschen", was passiert. Da müssten auch einige Posts dabei sein, die zeigen, was ausgegeben werden sollte.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: astro0302 am 31 Oktober 2017, 22:12:37
Danke schon einmal für die Antwort. Flashen über dfu-util scheint nicht zu funktionieren. Der Maple wird von Windows erkannt (USB7) und zeigt nach einem Reset auch das Blinkverhalten mit ca. 4Hz. Es kommt allerdings die Info:

C:\Temp\flash\dfu-util-0.9-win64>dfu-util dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Cannot open DFU device 1eaf:0003
No DFU capable USB device available




Vendor DeviceID sagt bei mir statt 1eaf:0003, dass 1eaf:0004 vorhanden wäre.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: astro0302 am 31 Oktober 2017, 22:35:07
Nach manueller Installation des Drivers mit Anlegen eines Devices mit der VID 1EAF:0003 über Zadig hat das Flashen funktioniert:

C:\Temp\flash\dfu-util-0.9-win64>dfu-util dfu-util --device 1eaf:0003 --alt 1 --download MapleCUNx4_W5500_BL.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [=========================] 100%        65328 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!


Es blinkt immer noch nicht, nur während des Bootvorganges. Über DHCP scheint er immer noch keine IP zu erhalten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 31 Oktober 2017, 22:59:39
Du brauchst zuerst den richtigen Bootloader siehe der Anleitung von Telekatz.
Wenn der passt die genau dazu passende Firmware.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: astro0302 am 31 Oktober 2017, 23:19:27
Ich teste geraden den Maple, den ich von Dir erhalten habe. Welchen Bootloader verwendest Du dafür, ich habe jetzt mit dem maple_mini_boot20.bin getestet.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 31 Oktober 2017, 23:29:40
Ich verwende diese:

Zitatrwxr-xr-x  4 martin martin   4096 Jul  4 16:35 .
drwxr-xr-x 67 martin martin   4096 Okt 31 14:48 ..
-rwxr-xr-x  1 martin martin    454 Jun  8 10:01 1_FlashBL-ttyUSB0.sh                                                                                                                   
-rwxr-xr-x  1 martin martin    454 Jun  8 10:01 1_FlashBL-ttyUSB1.sh                                                                                                                   
-rwxr-xr-x  1 martin martin    454 Jun 24 16:27 1_FlashBL-ttyUSB2.sh                                                                                                                   
drwxr-xr-x  2 martin martin   4096 Jul  4 16:33 20170628                                                                                                                               
-rwxr-xr-x  1 martin martin    338 Mär 30  2017 2_FlashCUX.sh                                                                                                                           
drwxrwxr-x  2 martin martin   4096 Jul  4 16:35 a-culfw_1.24.02_build_209                                                                                                               
-rw-rw-r--  1 martin martin    534 Jun  8 10:02 flash.tar.gz                                                                                                                           
-rwxr-xr-x  1 martin martin  65768 Jun 28 20:46 MapleCUNx4_W5100_BL.bin                                                                                                                 
-rwxr-xr-x  1 martin martin  65300 Jun 28 20:46 MapleCUNx4_W5500_BL.bin                                                                                                                 
-rw-r--r--  1 martin martin   7124 Mär  6  2017 maple_mini_boot20.bin                                                                                                                   
-rw-r--r--  1 martin martin   1710 Mär  6  2017 README.md                                                                                                                               
-rwxr-xr-x  1 martin martin 104264 Mär  6  2017 stm32flash                                                                                                                             

Du kannst mir auch eine Mail senden und bekommst wenn gewünscht das ganze Verzeichnis.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Lutze53 am 01 November 2017, 03:24:12
Nochmal auf mein Post zurückzukommen, auf den Bildern von Dem Cul ist der Maplemini immer auf einer
grossen Platine aufgelötet und genau die meinte ich wo man die her bekommt oder was das für eine ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 November 2017, 07:58:35
Ich versuche es nochmals. Du kannst Dir solche Platinen selbst machen lassen, oder ich geb dir eine ab.

Denke du meinst diese:
https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/Archiv/V2.1
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 November 2017, 08:12:38
Ich hab nochmals nachgedacht. Es mach doch meist Sinn die Sachen der Reihe anch anzugehen:
https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres

Also einfach mal schauen ob die drei ACM Devices angelegt werden wenn du das Teil an einen USB-Port am besten an einem Linux Rechners anschliesst.
-Wenn ja läuft die Pirmware
-Wenn nein läuft sie nicht
Mögliche Lösung: korrekt flashen (Bootloader passend zur Firmware)

Zum Thema Anpingen:
-leuchtet die grüne LED am LAN Modul sofort beim einstecken und dann blinkt die gelbe einige Male ?
-Wenn nicht: Kein Ping möglich
Möglicher Grund wenn alles andere ausgeschlossen ist: Ich habe zwei-drei LAN Module gesehen wo die LAN Buchse (hinten) nicht an allen Pins verlötet war

Zitat von: astro0302 am 31 Oktober 2017, 21:21:11
Jemand eine zündende Idee was ich falsch gemacht habe bzw. eine Möglichkeit zur Analyse?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: astro0302 am 01 November 2017, 22:01:50
Zitat von: Ranseyer am 01 November 2017, 08:12:38
Ich hab nochmals nachgedacht. Es mach doch meist Sinn die Sachen der Reihe anch anzugehen:
https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres

Also einfach mal schauen ob die drei ACM Devices angelegt werden wenn du das Teil an einen USB-Port am besten an einem Linux Rechners anschliesst.
-Wenn ja läuft die Pirmware
-Wenn nein läuft sie nicht
Mögliche Lösung: korrekt flashen (Bootloader passend zur Firmware)

Zum Thema Anpingen:
-leuchtet die grüne LED am LAN Modul sofort beim einstecken und dann blinkt die gelbe einige Male ?
-Wenn nicht: Kein Ping möglich
Möglicher Grund wenn alles andere ausgeschlossen ist: Ich habe zwei-drei LAN Module gesehen wo die LAN Buchse (hinten) nicht an allen Pins verlötet war

Hallo Ranseyer!

Vielen Dank für Deine email mit Deinen Bin-Dateien. Diese haben funktioniert. Keine Ahnung warum die Bin-Dateien, die ich aus Github geszogen habe, nicht funktioniert haben.

Der MapleCUN ist bereits in´s Netzwerk eingebunden, DHCP funktioniert problemlos.

In FHEM habe ich den MapleCUN auch bereits eingebunden. MapleCUN1 wird mit 868 MHz erkannt und MapleCUN2 mit 433 MHz. Top. Die Tage muss ich das dann ´mal aus dem Bastelkeller unter das Dach setzen und mein FHEM Skript umschreiben, damit die Dosen unter dem Dach dann vom MapleCUN geschaltet werden.

Ein Teil der Dosen werde ich in Zukunft allerdings durch Sonoff-Dosen ersezten. Diese werden direkt über IP angesprochen. Zum Test habe ich mir die Tage eine bestellt.  Ich sehe es schon kommen, irgendwann muss ich meine Subnetzmaske anpassen....

Zum Thema Ping: Der W5500 leuchtet bereits dauerhaft grün (Link) bzw. die gelbe LED blinkt (Daten) auch wenn keine IP per DHCP vergeben worden ist. Dieses Verhalten ist auch vollkommen normal.

Danke nochals für die BIN-Dateien.




Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 November 2017, 22:30:06
Zitatdie gelbe LED blinkt (Daten) auch wenn keine IP per DHCP vergeben worden ist.

Jawohl. Aber wenn das nicht passiert macht es auch keinen Sinn weiter zu machen...

Prima dass es nun läuft !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 05 November 2017, 10:12:58
Ich frag mal hier im Forum: Kann ich die blaue LED ausschalten? Ausser Eding und auslöten ;-))
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 05 November 2017, 10:18:58
ZitatAusser Eding und auslöten ;-))

Der Tipp war von mir und richtet sich an alle die nicht von selbst den Source neu kompilieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 05 November 2017, 10:23:23
@stgeran:

set CUL1 raw l02 = LED blinkt (1 Hz, Standard)
set CUL1 raw l00 = LED blinkt nur bei Sendung
set CUL1 raw l01 = LED ist dauern an


Steht im WIki.  :D
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 05 November 2017, 10:26:51
Ich sprach von: AUS
Das AUS ist nicht geschrien ;-)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 05 November 2017, 10:29:09
Dann hast du doch alle Antworten !

-selber coden
-SW konfigurieren
-frickeln
-damit Leben
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 05 November 2017, 10:33:54
set CUL1 raw l00 = LED blinkt nur bei Sendung
Ist wohl noch eine gute Alternative. Danke erstmal.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 05 November 2017, 15:50:49
Warum schaltet sich mein 433 MAPLECUL ständig von meinen eingestelltem Modus SlowRf in HomeMatic um? Nach der Einrichtung hat es einen halben Tag funktioniert und werte der Wetterstation aufgenommen. Nach dem Umschalten natürlich nicht mehr.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 05 November 2017, 15:55:25
Da wäre das verbose 5 - Log des CULs dazu interessant ..  ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 05 November 2017, 16:42:12
Hab ich gemacht. rfmode auf SlowRf Verbose 5 und shutdown restart
2017.11.05 16:38:08 5: protocol does not match, ignore received package (AAAAAA80EF) Reason: Not a hideki protocol
2017.11.05 16:38:40 0: Server shutdown
2017.11.05 16:38:40 5: SW: X00
2017.11.05 16:38:42 1: Including fhem.cfg
2017.11.05 16:38:42 3: telnetPort: port 7072 opened
2017.11.05 16:38:42 3: WEB: port 8083 opened
2017.11.05 16:38:42 3: WEBphone: port 8084 opened
2017.11.05 16:38:42 3: WEBtablet: port 8085 opened
2017.11.05 16:38:43 2: eventTypes: loaded 2277 events from ./log/eventTypes.txt
2017.11.05 16:38:43 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.11.05 16:38:43 3: Opening HMLAN1 device 192.168.100.110:1000
2017.11.05 16:38:43 1: HMLAN_Parse: HMLAN1 new condition init
2017.11.05 16:38:43 3: HMLAN1 device opened
2017.11.05 16:38:43 3: myHmUART device closed
2017.11.05 16:38:43 3: Opening myHmUART device /dev/ttyAMA0
2017.11.05 16:38:43 3: Setting myHmUART serial parameters to 115200,8,N,1
2017.11.05 16:38:43 3: myHmUART device opened
2017.11.05 16:38:45 3: define Controler_LED: can't reach (IO::Socket::INET: connect: timeout)
2017.11.05 16:38:46 3: Opening MAPLECUL868 device 192.168.100.161:2323
2017.11.05 16:38:46 3: MAPLECUL868: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2017.11.05 16:38:46 2: Setting MAPLECUL868 fhtid from 0000 to 4444
2017.11.05 16:38:46 3: MAPLECUL868 device opened
2017.11.05 16:38:46 2: Switched MAPLECUL868 rfmode to HomeMatic
2017.11.05 16:38:46 3: Opening MAPLECUL433 device FHEM:DEVIO:MAPLECUL868Stack:9600
2017.11.05 16:38:46 3: MAPLECUL433: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.11.05 16:38:46 2: Setting MAPLECUL433 fhtid from 4444 to 0000
2017.11.05 16:38:46 3: MAPLECUL433 device opened
2017.11.05 16:38:46 1: Including ./log/fhem.save
2017.11.05 16:38:46 3: Device Aussen_Temp added to ActionDetector with 000:10 time
2017.11.05 16:38:46 3: Device HM_Wand added to ActionDetector with 000:10 time
2017.11.05 16:38:46 3: Device K_1_Temp added to ActionDetector with 000:10 time
2017.11.05 16:38:46 3: Device K_2_Temp added to ActionDetector with 000:10 time
2017.11.05 16:38:47 5: SW: Zx
2017.11.05 16:38:47 5: SW: X21
2017.11.05 16:38:47 5: SW: Ar
2017.11.05 16:38:47 2: Switched MAPLECUL433 rfmode to HomeMatic
2017.11.05 16:38:47 1: define VCCU_Btn86 CUL_HM 0x123456: wrong syntax: define <name> CUL_HM 6-digit-hex-code [Raw-Message]
2017.11.05 16:38:47 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4144.
2017.11.05 16:38:47 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 7226.
2017.11.05 16:38:47 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 7551.
2017.11.05 16:38:47 1: PERL WARNING: Use of uninitialized value $name in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 7553.
2017.11.05 16:38:47 1: PERL WARNING: Use of uninitialized value $name in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 7554.
2017.11.05 16:38:47 1: PERL WARNING: Use of uninitialized value $name in string eq at ./FHEM/10_CUL_HM.pm line 7555.
2017.11.05 16:38:47 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 7240.
2017.11.05 16:38:47 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4050.
2017.11.05 16:38:48 3: Controler_LED low level cmd queue send ERROR 3100000000000031, qlen 1 (reconnect giving up)
2017.11.05 16:38:48 1: usb create starting
2017.11.05 16:38:48 3: Probing CUL device /dev/ttyS0
2017.11.05 16:38:48 1: usb create end
2017.11.05 16:38:48 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.11.05 16:38:48 0: Featurelevel: 5.8
2017.11.05 16:38:48 0: Server started with 132 defined entities (fhem.pl:15294/2017-10-20 perl:5.024001 os:linux user:fhem pid:17309)
2017.11.05 16:38:48 1: HMLAN_Parse: HMLAN1 new condition ok
2017.11.05 16:38:49 3: CUL_HM set Bad_Spiegel_Sw_01 statusRequest
2017.11.05 16:38:49 5: CUL/RAW: /A0B20A0011234563B5C5D010ED6

2017.11.05 16:38:49 4: CUL_Parse: MAPLECUL433 A 0B 20 A001 123456 3B5C5D 010ED6 -95
2017.11.05 16:38:49 5: MAPLECUL433: dispatch A0B20A0011234563B5C5D010E::-95:MAPLECUL433
2017.11.05 16:38:49 5: CUL/RAW: /A0E20A4103B5C5D123456060100005D05

2017.11.05 16:38:49 4: CUL_Parse: MAPLECUL433 A 0E 20 A410 3B5C5D 123456 060100005D05 -71.5
2017.11.05 16:38:49 5: MAPLECUL433: dispatch A0E20A4103B5C5D123456060100005D::-71.5:MAPLECUL433
2017.11.05 16:38:49 5: CUL/RAW: /A0A2080021234563B5C5D00D6

2017.11.05 16:38:49 4: CUL_Parse: MAPLECUL433 A 0A 20 8002 123456 3B5C5D 00D6 -95
2017.11.05 16:38:49 5: MAPLECUL433: dispatch A0A2080021234563B5C5D00::-95:MAPLECUL433

jump to the top

Ich stell das Verbose wieder zurück.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 November 2017, 20:47:34
Zitat von: stgeran am 05 November 2017, 15:50:49
Warum schaltet sich mein 433 MAPLECUL ständig von meinen eingestelltem Modus SlowRf in HomeMatic um?
Ich tippe mal darauf, dass dein 433 MAPLECUL in der IOList deiner vccu steht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 06 November 2017, 22:48:10
Ich habe keinen 433 MAPLECUL. Beide sind grün und jetzt auch mit 868MHz vorhanden. Wieso der eine meinte ein 433MHz zu sein weis ich nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 07 November 2017, 08:01:44
Der CUL weiss nicht welche Frequenz er tatsächlich hat.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 07 November 2017, 14:55:10
Aber wenn er mit ccconf 433MHz ausgibt muss ich das erst mal glauben, oder wie sag ich ihm welche Frequenz er hat?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 07 November 2017, 16:41:40
cconf sagt welche Freqenz verwendet wird. Nicht welche HW du hast. Das bedeutet er funkt gemäß ccconf und wenn die HW nicht dazu passt mit schlechter Reichweite.

An dieser Stelle wäre Doku studieren nicht ganz falsch gewesen..
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 08 November 2017, 06:32:50
Trotzdem verstehe ich nicht woher der CUL weis, mit welcher Frequenz er senden soll. Ich denke, die HW gibt das vor. Warum die denkt eine andere Frequenz zu nehmen als sie selbst ist verstehe ich nicht. Da hilft die Doku auch nicht weiter.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 08 November 2017, 09:44:06
Nochmals anders: Die Firmware kann nur den Transceiver Chip erkennen. Nicht aber wie dieser Frequentmäßig beschaltet ist.
Also muss du einfach per FHEM die zur HW passende Frequenz einstellen. Dazu hilft dir die Doku.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 08 November 2017, 11:34:01
Ok, jetzt hab ich verstanden.
Nur: in der Wiki finde ich mMn nichts, was auf das Einstellen der Frequenz hinweist. Welche Doku meinst Du?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Omega-5 am 08 November 2017, 17:35:59
Zitat von: stgeran am 08 November 2017, 11:34:01
Ok, jetzt hab ich verstanden.
Nur: in der Wiki finde ich mMn nichts, was auf das Einstellen der Frequenz hinweist. Welche Doku meinst Du?

Vieleicht schaust du auch mal im Wiki unter "CUL" oder um die Unterschiede bei den CC1101_Modulen zu verstehen auch mal bei "Selbstbau CUL" vorbei. Das IC CC1101 kann über seine Register universell eingestellt werden, die Module sind auf Grund der externen Beschaltung auf einen Frequenzbereich fest gelegt. Aber das hat Ranseyer eigentlich schon alles gesagt.

Gruß Friedrich
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 13 November 2017, 12:20:48
Zitat von: Omega-5 am 08 November 2017, 17:35:59
Vieleicht schaust du auch mal im Wiki unter "CUL" oder um die Unterschiede bei den CC1101_Modulen zu verstehen auch mal bei "Selbstbau CUL" vorbei. Das IC CC1101 kann über seine Register universell eingestellt werden, die Module sind auf Grund der externen Beschaltung auf einen Frequenzbereich fest gelegt. Aber das hat Ranseyer eigentlich schon alles gesagt.

Gruß Friedrich
@Stgeran, konntest du dem Problem inzwischen lösen?

Gesendet von meinem VTR-L09 mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: neumann am 16 November 2017, 13:23:29
Hey!
Ich habe folgendes Problem: Sobald ich mit meinem MapleCUN einen 433 MHz Befehl sende, der IT Repetition verwendet, klappt das senden solange auf dieser Frequenz nicht, bis ich den MapleCUN (angeschlossen über USB) neu starte und das repetition Attribut entferne. Ich verwende die a-culfw.

Woran liegt das?

Danke!

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Nov 15 2017 16:19:37 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x18
-I- Not detected CC2: PN 0x00  VER 0x00
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Not detected ethernet
-I- Not detected onewire
-I- init USB
-I- init Complete
0:Set RF mode to 1
0:Set RF mode to 2
1:Set RF mode to 1
1:Set RF mode to 11
1:Set RF mode to 1


2017.11.15 18:04:05 3: mapleCUL2 IT_set: steckdose on
2017.11.15 18:04:05 5: SW: *isr6
2017.11.15 18:04:05 5: CUL/RAW (ReadAnswer): *6

2017.11.15 18:04:05 5: SW: *is11011101101110100010000000010010
2017.11.15 18:04:06 5: CUL/RAW (ReadAnswer): *is11011101101110100010000000010010

2017.11.15 18:04:06 5: SW: *isr6
2017.11.15 18:04:06 5: CUL/RAW (ReadAnswer): *6

2017.11.15 18:04:06 3: IT set ITrepetition back: isr6 for mapleCUL2
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 16 November 2017, 19:38:52
Probier mal folgende Änderung:

diff --git a/culfw/clib/intertechno.c b/culfw/clib/intertechno.c
index f2aab6f..669398f 100644
--- a/culfw/clib/intertechno.c
+++ b/culfw/clib/intertechno.c
@@ -512,7 +512,11 @@
DU(it_interval,0); DNL();
} else if (in[1] == 's') {
         if (in[2] == 'r') { // Modify Repetition-counter
+#ifdef ARM
+            fromdec8(in+3, &it_repetition);
+#else
             fromdec (in+3, (uint8_t *)&it_repetition);
+#endif
             MULTICC_PREFIX();
             DU(it_repetition,0); DNL();
#ifdef HAS_HOMEEASY
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 17 November 2017, 18:08:40
@Ranseyer: Jetzt senden beide auf 868 MHz
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 17 November 2017, 18:19:47
Also Problem erledigt ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stgeran am 17 November 2017, 19:01:16
Yes ;-)))

Ach, noch was: gibt es ein passendes Gehäuse für den großen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 17 November 2017, 19:06:59
Guggst du hier: https://wiki.fhem.de/wiki/MapleCUX-Platinen#Geh.C3.A4use
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: neumann am 18 November 2017, 11:40:21
Zitat von: Telekatz am 16 November 2017, 19:38:52
Probier mal folgende Änderung:

diff --git a/culfw/clib/intertechno.c b/culfw/clib/intertechno.c
index f2aab6f..669398f 100644
--- a/culfw/clib/intertechno.c
+++ b/culfw/clib/intertechno.c
@@ -512,7 +512,11 @@
DU(it_interval,0); DNL();
} else if (in[1] == 's') {
         if (in[2] == 'r') { // Modify Repetition-counter
+#ifdef ARM
+            fromdec8(in+3, &it_repetition);
+#else
             fromdec (in+3, (uint8_t *)&it_repetition);
+#endif
             MULTICC_PREFIX();
             DU(it_repetition,0); DNL();
#ifdef HAS_HOMEEASY


Super! Damit klappt ITRepetition. Danke!

Jetzt habe ich noch das Problem, dass senden von 433 MHz mit meinen Chips nicht funktioniert (die Geräte schalten nicht). Mit den Standard 868 MHz Chips im SlowRF Modus geht es.
Mit Telekatz habe ich schon per PN geschrieben und wir kamen darauf, dass es eventuell an den Chips liegt: https://de.aliexpress.com/store/product/RTC1101-high-performance-wireless-FSK-transceiver-module-CC1101-radio-transceiver-chip-600-meters-1200bps-433-Mhz/704833_32472259186.html (https://de.aliexpress.com/store/product/RTC1101-high-performance-wireless-FSK-transceiver-module-CC1101-radio-transceiver-chip-600-meters-1200bps-433-Mhz/704833_32472259186.html)

Als Vergleich habe ich den gleichen Befehl mal aufgezeichnet - RTC1101 ist hierbei der blaue CC1101 von Aliexpress, C1101 der Standard 868 MHz Chip im Slow RF Modus und nanoCUL ist mit dem länglichen 433 MHz Antennen Layout.
https://puu.sh/yoxxr/d2683d0e02.png (https://puu.sh/yoxxr/d2683d0e02.png)

Habt ihr eine Idee?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 Dezember 2017, 11:11:29
Mal wieder etwas Feedback.

Ich hatte mich schon gewundert wie manche es schaffen die USB Buchse am Maple zu ruinieren.
Fakt ist eine Charge die ich bekommen habe, hat absolut üble Buchsen. Außerdem sind einzelne Exemplare instabil.
Das habe ich auch per PN bestätigt bekommen. PS: Ich empfehle inzwischen die von "Bates" !

Zitat von: neumann am 01 Dezember 2017, 09:18:51
Riesen dank an dich, es lag tatsächlich an dem Maple, ich hatte gleich zwei defekte.
Habe jetzt einen dritten, aber mit Bates Logo, verbaut und der funktioniert perfekt!

Die Platine habe ich wieder mehr an meine eigenen Vorstellungen angepasst: Allen unnützen "Mist" herunter, dafür aber ein Addon für
A) RFM69 und die Möglichkeit den HM-Mod-UART auszulagern (der ist mir zu teuer um ihn direkt zu verlöten); Nebenbei: RS485, NRF*
B) 1Wire: Habe ich nicht bestellt, nutze ich nicht.
Die Addons sind Alpha. Die V3 Platine ist Stable und gefällt mir inzwischen sehr gut ! Nun fhelt mir nur noch ein druckbares Gehäuse dazu als Alternative zu den käuflichen...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 01 Dezember 2017, 13:35:49
Hi Ranseyer,

das kann ich bestätigen.
Meine USB Buchse ging auch nach 20 mal ein/ausstecken kaputt.
Musste dann den Maple nochmal auslöten und durch einen neuen ersetzen.
Nun ist alles super.
Bin total zufrieden mit der Platine von dir.

Da ich jetzt etwas von Gehäusen gelesen habe wollte ich mal fragen welche du da benutzt.
Kennst du passende gehäuse? Ich habe aber die kleine Platine.

Danke und Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 Dezember 2017, 13:52:43
Hi,

die kleine Platine ist nicht für Gehäuseeinbau, sondern Schrumpfschlauch vorgesehen. (Man könnte sich jedoch eins konstruieren und drucken)

Für die Große Version gibt es hier Infos: https://wiki.fhem.de/wiki/MapleCUX-Platinen#Geh.C3.A4use

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 02 Dezember 2017, 00:16:30
Super Danke!
Schrumpfschlauch ist nicht so ganz meins.
Ich geh mal etwas auf die Suche für die Maße der kleinen.
Einen 3d Drucker hab ich leider nicht.

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 02 Dezember 2017, 12:20:44
Hallo Stefan,
wenn Du Deine Wunsch-Vorstellungen zu Papier (bemaßt, ähm PDF o.Ä. ... ) bringen kannst ....

Bin eh die nächste Zeit wieder am Gehäuse (https://forum.fhem.de/index.php/topic,72777.0.html)-"Designen" ....


Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 02 Dezember 2017, 12:30:03
Das wäre toll Jürgen.

Ich mache mich mal dran und schicke dir die Bemaßungen und meine Vorstellung per PDF.

Vielen Dank für das Angebot.

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 04 Dezember 2017, 21:06:41
Hier der erste Entwurf zum Gehäuse:
https://forum.fhem.de/index.php?topic=80567.msg725930#msg725930 (https://forum.fhem.de/index.php?topic=80567.msg725930#msg725930)
in der 3D-Ecke.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 Dezember 2017, 17:09:50
Ich bin inzwischen meinem Ideal recht nahe gekommen:
-hinderliches Zeug ausgelagert
-flexibel
-ziemlich "easy", also meist ist die Montagereihenfolge egal. (Trotzdem mitdenken!)

Anbei ein paar Bilder.

PS: Das AddOn (RFM69, HM-Mod-UART, RS485, notfalls NRF24L01, Arduino, ATMEGA diskret=ungetestet!) hat nichts mit dem Projekt von Telkatz zu tun und zeigt nur was man mit etwas Kreativität aus dem Projekt herausholen kann. Fragen dazu bitte keinesfalls hier sondern in einem meiner Threads...

PPS: Ich hab mich mal an der Doku zur Einbing der UART-Erweiterungen versucht: https://wiki.fhem.de/wiki/MapleCUX-Platinen#Konfiguration_f.C3.BCr_die_AddOnPlatine


Quellen:
https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/Archiv/V3.0
https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/AddOns

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Phili am 18 Dezember 2017, 18:22:55
Hallo zusammen,

Ich komme nicht weiter und brauche bitte Unterstützung. Ich habe einen 4fach cun mit LAN Port. Den LAN Port hab ich mit statischer IP versehen, da dass mit dem DHCP nicht so richtig funktioniert hat.

Verbindung über LAN steht und ich kann die cconf für alle 4 cul abrufen.

Die Frequenzen habe ich für cc00 bis cc02 setzen können. Bei cc03 übernimmt er die Frequenz nach einem fhem Neustart leider nicht. Bestückung ist meiner Meinung nach wie folgt:

0=868
1=433
2=868
3=433 (steht immer auf 868)

(https://uploads.tapatalk-cdn.com/20171218/75497d4069f875368276e5b2971856e4.jpg)

Hat jemand eine Idee woran das liegt?

Gruß
Philipp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Dezember 2017, 18:50:49
Nur bei SlowRF muss man die Frequenz manuell setzen. Da SlowRF nicht an cc3 funktioniert wird da auch nichts gespeichert.
Die anderen Protokolle stelle automatisch die passende Frequenz ein.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 18 Dezember 2017, 18:53:38
My MapleCun IS working with DHCP. According https://wiki.fhem.de/wiki/MapleCUN SlowRF is supported ONLY for CC0 and CC1 so I don't know if putting 433MHz on CC3 is a good idea (Are there any "non SlowRF" devices for 433 MHz)? I've some problems with stability but because of USB power problems (I hope). Questions (a few):

1) My first setup was without ethernet module and I could see 3 "serial ports" via USB. Now I've connected W5500: network is working I can connect to 2323 (working) but I can't see ANY serial devices via USB.
2) What's the purpose of network ports 2324 and 2325. Are there "just bridges" between UART0 and UART1?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: blueicechip am 18 Dezember 2017, 19:19:57
1) you can only use LAN or USB, not both together.
2) yes these are bridge ports
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 18 Dezember 2017, 19:24:10
Last question:

For MapleCUN TTY_BUFSIZE is set for 256 bytes

#define TTY_BUFSIZE          256      // RAM: TTY_BUFSIZE*4

Is it wise?  E.x for MegaCul buffer is set on 1024. There is plenty of RAM in STM32 why these setting is set so low?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 18 Dezember 2017, 19:27:48
And one more question ;-) According https://wiki.fhem.de/wiki/MapleCUN

"KOPP and MBUS only work on CC0" but a few lines bellow there is a statement "MBUS works on each transceiver but not on more than one transceiver at a time."

I presume that second is true (first one is probably true for older versions).
 
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: blueicechip am 18 Dezember 2017, 20:41:37
@bilbobotz

- yes - the most protocols can work in every ccx port
- you not realy need to change the buffersize, these Mikrocontrollers has very less RAM, otherwise they are very fast. And the most RAM is used by the RF receive buffer and the protocol decoders.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Dezember 2017, 20:54:44
Zitat von: blueicechip am 18 Dezember 2017, 19:19:57
1) you can only use LAN or USB, not both together.
No, it is also possible to connect via LAN and USB at the same time.


Zitat von: bilbolodz am 18 Dezember 2017, 19:24:10
Is it wise?  E.x for MegaCul buffer is set on 1024. There is plenty of RAM in STM32 why these setting is set so low?
Do you need more? Is it wise to size the buffer larger than required?
It's not just one buffer of this size. The MapleCUN has six of these buffers.


Zitat von: bilbolodz am 18 Dezember 2017, 19:27:48
And one more question ;-) According https://wiki.fhem.de/wiki/MapleCUN

"KOPP and MBUS only work on CC0" but a few lines bellow there is a statement "MBUS works on each transceiver but not on more than one transceiver at a time."

I presume that second is true (first one is probably true for older versions).
 
Yes, the second statement is true.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 18 Dezember 2017, 21:20:30
Zitat von: blueicechip am 18 Dezember 2017, 20:41:37- you not realy need to change the buffersize, these Mikrocontrollers has very less RAM, otherwise they are very fast. And the most RAM is used by the RF receive buffer and the protocol decoders.
Very less RAM? According data sheet there is 20kb RAM, that's quite decent value as for such MC.

Zitat von: Telekatz am 18 Dezember 2017, 20:54:44No, it is also possible to connect via LAN and USB at the same time.
Hmmmm. Strange after connecting MapleCUN I can only see (dmesg):
[21481.548453] usb 1-7.1: new full-speed USB device number 15 using xhci_hcd
[21481.650328] usb 1-7.1: New USB device found, idVendor=1eaf, idProduct=0003
[21481.650334] usb 1-7.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[21481.650337] usb 1-7.1: Product: Maple 003
[21481.650340] usb 1-7.1: Manufacturer: LeafLabs
[21481.650342] usb 1-7.1: SerialNumber: LLM 003

No serial devices..... What could be wrong? I'm using stm32 blue pill board instead maple board (for a while waiting for ebay parcel). I've some problems with flashing it maybe it's connected with it?

Zitat von: Telekatz am 18 Dezember 2017, 20:54:44
Do you need more? Is it wise to size the buffer larger than required?
It's not just one buffer of this size. The MapleCUN has six of these buffers.
I'm trying to decode WMbus. I can see messages in logs:
2017.12.18 14:50:34 2: WMBUS Error during LinkLayer parse:message too short, expected 156, got 143 bytes

In another topic connected  WMBUS there was a suggestion to increase buffer size.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Dezember 2017, 21:51:19
Zitat von: bilbolodz am 18 Dezember 2017, 21:20:30
Hmmmm. Strange after connecting MapleCUN I can only see (dmesg):
[21481.548453] usb 1-7.1: new full-speed USB device number 15 using xhci_hcd
[21481.650328] usb 1-7.1: New USB device found, idVendor=1eaf, idProduct=0003
[21481.650334] usb 1-7.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[21481.650337] usb 1-7.1: Product: Maple 003
[21481.650340] usb 1-7.1: Manufacturer: LeafLabs
[21481.650342] usb 1-7.1: SerialNumber: LLM 003

No serial devices..... What could be wrong? I'm using stm32 blue pill board instead maple board (for a while waiting for ebay parcel). I've some problems with flashing it maybe it's connected with it?
I think the problem is the USB reset circuit which is not existent on the blue pill. The blue pill need a different USB reset method.  Which version of the STM32duino bootloader do you use?

Zitat von: bilbolodz am 18 Dezember 2017, 21:20:30
I'm trying to decode WMbus. I can see messages in logs:
2017.12.18 14:50:34 2: WMBUS Error during LinkLayer parse:message too short, expected 156, got 143 bytes

In another topic connected  WMBUS there was a suggestion to increase buffer size.
Then 512 should be enough.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 18 Dezember 2017, 21:57:29
Zitat von: Telekatz am 18 Dezember 2017, 21:51:19
I think the problem is the USB reset circuit which is not existent on the blue pill. The blue pill need a different USB reset method.  Which version of the STM32duino bootloader do you use?
generic_boot20_pc13.bin
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Dezember 2017, 23:12:21
Should be the right on. But as noted in the readme of the STM32duino-bootloader it is not guaranteed that the reset method will always work properly.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 18 Dezember 2017, 23:33:11
Zitat von: Telekatz am 18 Dezember 2017, 23:12:21
Should be the right on. But as noted in the readme of the STM32duino-bootloader it is not guaranteed that the reset method will always work properly.
First I've connected just with wires only one RF1101SE and serial ports were working fine. After soldering PCB (3 RF modules and W5500) and connecting by wire Blue Pill to PCB ethernet was working but serial ports not. Strange.....
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Phili am 19 Dezember 2017, 08:35:08
Zitat von: Telekatz am 18 Dezember 2017, 18:50:49
Nur bei SlowRF muss man die Frequenz manuell setzen. Da SlowRF nicht an cc3 funktioniert wird da auch nichts gespeichert.
Die anderen Protokolle stelle automatisch die passende Frequenz ein.

Super danke, macht Sinn!

Ich würde gern mit cc01 intertechno schalten, muss ich dafür auch die Änderungen durchführen, die du ein paar Beiträge zuvor bzgl. ITRepetition geschrieben hast?

Gruß
Philipp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Phili am 19 Dezember 2017, 21:53:47
Noch eine Frage:

IT Steckdosen kann ich jetzt schalten, jedoch nur über c00 (868). Wobei es so aussieht, als ob der Befehl an cc01 (433,92) weitergegeben wird:
2017.12.19 21:41:45.784 3: mapleCUN1 IT_set: ELRO_10110_B off
2017.12.19 21:41:46.199 4: CUL_Parse: mapleCUN2 i155154F2 -81
2017.12.19 21:41:46.205 5: mapleCUN2: dispatch i155154
2017.12.19 21:41:46.208 4: mapleCUN2 IT: message "i155154" (7)
2017.12.19 21:41:46.210 4: mapleCUN2 IT: msgcode "0FFFFF0FFFF0" (12) bin = 000101010101000101010100
2017.12.19 21:41:46.211 5: mapleCUN2 IT: V1 housecode = 0FFFFF0FFF  onoffcode = F0
2017.12.19 21:41:46.213 3: mapleCUN2 IT: ELRO_10110_B off->off


Wenn ich das IOdef der Steckdose direkt auf cc01 setze geht es nicht mehr
2017.12.19 21:46:25.040 3: mapleCUN2 IT_set: ELRO_10110_B on
2017.12.19 21:46:25.412 5: CUL/RAW (ReadAnswer): *is0FFFFF0FFFFF


Ich verstehe das nicht :(.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 01 Januar 2018, 19:10:13
Hier mal ein Photo der leicht aktualisierten Small-Ausführung des CUL für den origalen MAPLE (Original soll meinen alles im 2,54mm Raster = leicht zu löten)

Aktualisiert habe ich den Footprint für Mini-Stamps (die sind dann etwas weniger leicht zu löten, aber wenn man Entlözlitze hat...)

Platinen dazu gibt es hier: https://forum.fhem.de/index.php?topic=80319
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 02 Januar 2018, 20:59:57
Hallo,

meine Platine (https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078) zeigt erweiterte Grundreflexe:
-I- Getting new Started Project --<\n><\r>
-I- MapleCUNx4<\n><\r>
-I- Compiled: Sep 18 2017 20:28:11 --<\n><\r>
-I- init Flash<\n><\r>
-I- init Timer<\n><\r>
-I- init EEprom<\n><\r>
-I- init Ethernet<\n><\r>
WIZCHIP Initialized success.<\n><\r>
-I- Detected CC0: PN 0x00  VER 0x14 <\n><\r>
-I- Detected CC1: PN 0x00  VER 0x14 <\n><\r>
-I- Not detected CC2: PN 0x00  VER 0x00 <\n><\r>
-I- Detected CC3: PN 0x00  VER 0x14 <\n><\r>
-I- Not detected ethernet <\n><\r>
-I- Detected onewire <\n><\r>
-I- init ONEWIRE<\n><\r>
-I- init USB<\n><\r>
-I- init Complete<\n><\r>


Mich irritiert etwas diese Zeile:
-I- init Ethernet WIZCHIP Initialized success.
da noch kein Ethernet Modul verbaut wird. Mal sehen, was passiert, wenn das Ding eingelötet ist.

Morgen kommt noch der MySensors Teil und dann wird das Ganze ins Gehäuse gebaut  ;D ;D ;D.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 Januar 2018, 21:14:04
Das ist normal siehe: https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres

Wenn das LAN Modul erkannt wird siehst du noch:
Zitat-I- Detected ethernet

ed: Der X41, welcher Verbinder ist das  ? (Finde ich interessant)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 03 Januar 2018, 07:59:03
Hallo Martin,

Zitat von: Ranseyer am 02 Januar 2018, 21:14:04
ed: Der X41, welcher Verbinder ist das  ? (Finde ich interessant)
das ist eine Stecker-/Buchsenkombination von Würth, siehe https://www.voelkner.de/products/686802/Wuerth-Elektronik-Einbau-Stiftleiste-Standard-WR-WTB-Polzahl-Gesamt-3-653103131822-Rastermass-1.25.html

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 06 Januar 2018, 13:57:25
Hallo zusammen,

hat jemand von Euch schon Erfahrung mit einem Atmega328P an USB0?

Ich habe folgendes probiert:
- Blink Sketch um einen Zähler erweitert, der liefert mit 11500 baud an /dev/ACM1 brav die entsprechende Zahl
- der Atmega328P hat einen Bootloader drauf, aber
sudo avrdude -p m328p -P /dev/ttyACM1 -c arduino  -V -U flash:w:/tmp/GatewaySerial_8MHz.hex
findet keinen Bootloader
- der MySensors Sketch funktioniert auch nicht
- der Sketch funktioniert aber auf anderen einem seriellen Gateway mit Arduino nano
- das NRF24L02 Modul funktioniert auch am seriellen Gateway

Bevor ich das LAN Modul bzw. das HMUART Modul auflöte, sollte klar sein, dass es nicht an der Hardware liegt.

Meine nächsten Schritte:
- Überprüfen der Verkabelung zum Transceiver (MySensors hat halt keine vernünftigen Schaltpläte)
Meine nächsten Schritte  ;D
- anlöten zweier dünnen Kable an Rx, Tx (ist leider nicht rausgeführt) das Booten des Gateways mitzuloggen

Habt ihr sonst noch Ideen?

Danke + Gruß

PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 06 Januar 2018, 15:48:54
Flashen des Arduinos geht nur bequem wenn auch auf der Arduino-Seite DTR verbunden ist.

Das LAN Modul könntest Du auf der ersten Platine ja auch nur stecken (Buchsenleiste). So eine Testplatine macht eh Sinn falls du LAN Module vor dem verlöten testen willst.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 06 Januar 2018, 18:53:23
fertig  ;D ;D ;D

Der MySensors Teil zickt noch etwas rum. Falls das nicht funktioniert, mache ich halt eine Adapterplatine für den RFM95 und mache einen seriellen Sketch für meine Photovoltaikanlage.
Testen muss ich noch 1-wire, da fehlt auch ein 100 Ohm Widerstand  ::), aber das sollte auch klappen.
Alles in allem kostet das Ganze doch mehr Zeit als ursprünglich gedacht  :o

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 06 Januar 2018, 23:59:33
Hallo zusammen,

wie wird denn das 1-wire Interface in FHEM definiert? Ich würde dafür OWX nehmen,
aber wie gebe ich die entsprechende serielle Schnittstelle an? Ist der Port bei LAN dann 23?

Danke + Gruß

PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Januar 2018, 11:00:28
1-wire habe ich bisher nur mit DS18B20 Sensoren getestet und dafür die HMS Emulation in der culfw verwendet.

Mit dem OWX Modul müsste es aber so wie für den CUNO beschrieben funktionieren:
define <name> OWX <cuno/coc-device>, i.e. specify the previously defined COC/CUNO to which the 1-Wire bus is attached, for example
define OWio2 OWX COC
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Mumpitz am 10 Januar 2018, 20:14:23
Hallo zusammen

Ich habe von Ranseyer eine 4-Fach CUL V3.0 Platine gekauft und mir die restlichen Bauteile vom Chinesen liefern lassen. Mittlerweile sind alle Bauteile eingetroffen und ich wollte eigentlich beginnen, die ganzen Bauteile aufzulöten.

Im Wiki steht, dass zur Stabilisation noch zwei Kondensatoren aufgelötet werden können (sollten). Ich habe dazu je einen 12 pF sowie einen 100 uF Kondensator zur Verfügung. Nur, ansoll ich diese auflöten?

Was ich möchte und habe:
Ich habe einen CC1101 868 MHz sowie einen CC1101 433 Mhz, welche ich auf CC0 resp. CC1 auflöten möchte.

Kann mir jemand einen Hinweis geben, an welcher Stelle ich welchen Kondenser einlöten soll?

Besten Dank
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 10 Januar 2018, 21:16:10
Hi,

du könntest mal studieren:
https://wiki.fhem.de/wiki/MapleCUX-Platinen#Aufbau

Den großen Kondensator z.B. bei C3: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Archiv/V3.0/V30-Bot.png
Dann noch falls Du Lust hast C1: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Archiv/V3.0/V30-Top.png

(Ich stelle gerade fest dass durch das Abspecken wieder mehr Platz für Abblockkondensatoren entstanden ist)

PS: Das ganze wird auch ohne die Kondensatoren laufen, aber man weis ja nie...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 10 Januar 2018, 21:20:20
Zitat von: Ranseyer am 10 Januar 2018, 21:16:10
PS: Das ganze wird auch ohne die Kondensatoren laufen, aber man weis ja nie...
Naja, ich habe bei meiner Platine an jedem CC1101 Modul einen 100 nF vorgesehen, das schadet auf jeden Fall nicht  ;D ;D ;D

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Mick59 am 11 Januar 2018, 17:37:50
Hallo,
habe endlich meine beiden MapleCun large V3 bestückt mit 4 x cc1101 davon 1x mit Pfostenstecker für 433MHz auf CC2.
SlowRf funktioniert ja mit der letzten Firmware dort auch. Leider kann ich keine IT Devices schalten, da das cmd i fehlt (cmds    
bCAZNELYVXfz). Kann mir jemand auf die Sprünge helfen wie ich das aktivieren kann ?

Gruß Mick
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 Januar 2018, 22:06:36
Das muss in der Firmware geändert werden. Mit der angefügten Version sollte es funktionieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Mick59 am 11 Januar 2018, 22:18:51
Es funktioniert,
vielen Dank für die schnelle Hilfe
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 14 Januar 2018, 18:57:32
Zitat von: Telekatz am 07 Januar 2018, 11:00:28
Mit dem OWX Modul müsste es aber so wie für den CUNO beschrieben funktionieren:
define <name> OWX <cuno/coc-device>, i.e. specify the previously defined COC/CUNO to which the 1-Wire bus is attached, for example
define OWio2 OWX COC

Leider nicht, er findet auf dem Bus kein 1-wire. Und mit den RAW Kommandos findet er manchmal den Busmaster und manchmal auch nicht  :o

Dafür ist die Mechanik jetzt komplett fertig, siehe Bilder.
Was noch nicht so ganz funktioniert:
- 1-wire
- MySensors Gateway: das geht immer mal wieder auf connected zurück und braucht dann einen Reset

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 15 Januar 2018, 19:18:37
Es funktioniert schon mit OWX, allerdings muss man es vorher noch patchen, damit der MapleCUN als Interface akzeptiert wird:
Index: 00_OWX.pm
===================================================================
--- 00_OWX.pm (revision 15437)
+++ 00_OWX.pm (working copy)
@@ -189,7 +189,7 @@
     $hwdevice = OWX_I2C->new($hash);
     
   #-- check if we have a COC/CUNO interface attached 
-  }elsif( (defined( $defs{$dev}->{VERSION} ) ? $defs{$dev}->{VERSION} : "") =~ m/CSM|CUNO/ ){
+  }elsif( (defined( $defs{$dev}->{VERSION} ) ? $defs{$dev}->{VERSION} : "") =~ m/CSM|CUNO|MapleCUN...(4|5|6|7|C|D|E|F)/ ){
     require "$attr{global}{modpath}/FHEM/11_OWX_CCC.pm";
     $hwdevice = OWX_CCC->new($hash);
     


define mapleCUL CUL 192.168.69.145:2323 1536
define MapleOWire OWX mapleCUL


OWX_Discover: 1-Wire devices found on bus MapleOWire
28.FFA416A41603      DS18B20        OWX_28_FFA416A41603
28.FF0A16A51603      DS18B20        OWX_28_FF0A16A51603
28.FFDB0FA41603      DS18B20        OWX_28_FFDB0FA41603


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Prof. Dr. Peter Henning am 16 Januar 2018, 10:16:40
Hab ich übernommen und eingecheckt.

LG

pah
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 18 Januar 2018, 21:15:55
Zitat von: PeMue am 14 Januar 2018, 18:57:32
Was noch nicht so ganz funktioniert:
- 1-wire
- MySensors Gateway: das geht immer mal wieder auf connected zurück und braucht dann einen Reset
Dank Telekatz und pah ist das Thema 1-wire mittlerweile auch abgehakt, die Sensoren (momentan nur Temperatur) werden anstanslos erkannt:
OWX_10_C175B5020800   T: 18.81 °C ↓
Danke nochmal.

Das MySensors Thema wird dann auch noch gelöst werden  ;)

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Prof. Dr. Peter Henning am 19 Januar 2018, 04:22:46
Könnte man dafür eine Wiki-Seite anlegen, ähnlich wie dieses uralte Teil von mir: https://wiki.fhem.de/wiki/CUNO_und_1-wire ?

LG

pah
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 19 Januar 2018, 22:40:41
Zitat von: Prof. Dr. Peter Henning am 19 Januar 2018, 04:22:46
Könnte man dafür eine Wiki-Seite anlegen, ähnlich wie dieses uralte Teil von mir: https://wiki.fhem.de/wiki/CUNO_und_1-wire ?
Hm, irgendwie scheitere ich gerade daran, dass ich nicht weiß, wie man eine neue Seite anlegt. Ich meine, ich hätte das schonmal gemacht, aber wenn man nicht alles aufschreibt  ::)
Ich werde aber dranbleiben.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 19 Januar 2018, 22:48:02
Einfach die URL im Browser so editieren wie die neues Seite heissen soll...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 20 Januar 2018, 07:09:49
Hallo pah,

Zitat von: Prof. Dr. Peter Henning am 19 Januar 2018, 04:22:46
Könnte man dafür eine Wiki-Seite anlegen, ähnlich wie dieses uralte Teil von mir: https://wiki.fhem.de/wiki/CUNO_und_1-wire ?
man hat eine Wiki Seite angelegt  ;), siehe https://wiki.fhem.de/wiki/MapleCUx_und_1-wire

Ich habe auf Deiner Seite die Referenz auf die Literatur angepasst. M.E. ist der HMS-T kein Homematic Device sondern SlowRF, d.h. ich habe es im Wiki Artikel für mapleCUx geändert.

Bitte gerne noch mal querlesen und ggf. Infos an mich, was noch geändert werden soll.

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 20 Januar 2018, 11:16:41
Für die 1-Wire Schaltung würde ich den angehängten Schaltplan nehmen. Bei dem ist dann auch der DS9503 richtig herum eingebaut.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 20 Januar 2018, 11:34:30
Zitat von: Telekatz am 20 Januar 2018, 11:16:41
Für die 1-Wire Schaltung würde ich den angehängten Schaltplan nehmen.
erledigt, und der R3 mit 100 Ohm im Massezweig fehlt dann (wie bei meiner Schaltung) auch  ;D

Gruß PeMue
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: arthur_dent_2015 am 02 Februar 2018, 16:17:46
Hallo,
habe mir gerade ein MapleCUN (3x 868, 1x 433)  mit LAN zugelegt und testweise in Betrieb genommen. der dritte 868 transmitter zeigt dabei ein seltsames Verhalten...  ???
Hier ein list vom device:

Internals:
   CFGFN     
   CMDS       CAZNELYVXfz
   Clients    :WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        mapleCUN3
   IODev      mapleCUN3
   MessageEncoding CUL
   NAME       mapleCUN4
   NOTIFYDEV  mapleCUN3
   NR         1070
   NTFY_ORDER 50-mapleCUN4
   PARTIAL   
   RAWMSG     ? (brt is unknown) Use one of C A Z N E L Y V X f z
   RSSI       -78
   STATE      Initialized
   StackLevel 3
   TYPE       STACKABLE_CC
   VERSION    V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_8F (F-Band: 868MHz)
   initString X21
brt
   mapleCUN4_MSGCNT 9
   mapleCUN4_TIME 2018-02-02 15:59:27
   Helper:
     DBLOG:
       ccconf:
         fhemlogDB:
           TIME       1517583586.36241
           VALUE      freq:800.000MHz bWidth:203KHz rAmpl:33dB sens:8dB
       cmds:
         fhemlogDB:
           TIME       1517583567.10781
           VALUE       C A Z N E L Y V X f z
       state:
         fhemlogDB:
           TIME       1517583567.2145
           VALUE      CONNECTED
   MatchList:
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     J:WMBUS    ^b.*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-02-02 15:59:46   ccconf          freq:800.000MHz bWidth:203KHz rAmpl:33dB sens:8dB
     2018-02-02 15:59:27   cmds             C A Z N E L Y V X f z
     2018-02-02 15:59:27   state           Initialized
     2018-02-01 19:45:07   version         V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_8F (F-Band: 868MHz)
   helper:
     bm:
       CUL_Get:
         cnt        9
         mAr        HASH(0x6faae78); mapleCUN4; ccconf
         max        139
         tot        258
       CUL_Set:
         cnt        53
         mAr        HASH(0x6faae78); mapleCUN4; freq; 868.300
         max        8
         tot        16
       STACKABLE_CC_AddPrefix:
         cnt        36
         mAr       
         max        0
         tot        0
       STACKABLE_CC_DelPrefix:
         cnt        25
         mAr       
         max        0
         tot        0
       STACKABLE_CC_Notify:
         cnt        6
         mAr        HASH(0x6faae78); HASH(0x6faa6c0)
         max        529
         tot        692
Attributes:
   icon       cul_868
   room       Transmitter
   verbose    4


get ccconf bringt das folgende Ergebnis:

mapleCUN4 ccconf => freq:800.000MHz bWidth:203KHz rAmpl:33dB sens:8dB


Das lässt sich zwar (manchmal) auf 868.300 ändern, aber nach restart steht die Frequenz wieder auf 800.000 :(

Jemand ne Idee?

Gruß
Arthur
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 02 Februar 2018, 17:02:32
Probier es mal mit einem Reset der Einstellungen (raw e).
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: arthur_dent_2015 am 02 Februar 2018, 17:39:32
tut sich nichts :-(
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 02 Februar 2018, 17:53:12
Hast du raw e am ersten oder am dritten CUL eingegeben?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: arthur_dent_2015 am 02 Februar 2018, 18:10:26
wenn ich set mapleCUN4 raw e mache gibts

mapleCUN4: Unknown code ? (e is unknown) Use one of C A Z N E L Y V X f z, help me!

als Antwort. Also auf mapleCUN 1 losgelassen. Da gab es keine Antwort. Anschließend hab ich noch set mapleCUN1 raw B00 abgesetzt. Danach set mapleCUN4 freq 868.300 mit anschließendem get mapleCUN4 ccconf ==> freq 800.000
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 02 Februar 2018, 18:24:35
Ach du meinst den vierten Transceiver. An dem geht kein SlowRF. Da kann man sich die freq Einstellung sparen. Die Protokolle, die da funktionieren, stellen sich ihre Frequenz selbst passend ein.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: arthur_dent_2015 am 02 Februar 2018, 18:36:34
Ich habs beim rumprobieren gerade selbst bemerkt. Auf rfmode MAX gestellt und ccconf sieht sauber aus :)

Danke trotzdem!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 Februar 2018, 20:13:10
Ich finde das schwer zu beschreiben, und Wikis liest eh keiner (?).

Trotzdem sollte es nun klarer sein: https://wiki.fhem.de/wiki/MapleCUN#Best.C3.BCckung_der_Module
Wer nicht dort schreiben kann/will und eine konkrete Idee hat: PN an mich...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: arthur_dent_2015 am 04 Februar 2018, 14:22:44

Durch die Wahl des Protokolls wird die Frequenz automatisch eingestellt.


Fett kursiv, mit dem Zusatz: und kann auch nicht geändert werden!
Das wäre dann sogar mir aufgefallen  :-[
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 Februar 2018, 15:15:43
Danke, guter Hinweis. Ist übernommen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 06 Februar 2018, 20:09:37
I'm interested in connecting ESP01 to MapleCUN as remote debug connection. Is there "ready to use" (preferable Arduino sketch) program?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 06 Februar 2018, 20:15:38
Hi, do you mean the ESP-LINK Software on the ESP and then access the serial via ip adress and port 23?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 06 Februar 2018, 20:16:26
Zitat von: RaspiLED am 06 Februar 2018, 20:15:38
Hi, do you mean the ESP-LINK Software on the ESP and then access the serial via ip adress and port 23?
Yes, exactly.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 06 Februar 2018, 20:30:59
Arnd means ths one: https://github.com/jeelabs/esp-link
(And yes: its good...)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 06 Februar 2018, 20:33:15
Thank Looks nice. I will check it.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 09 Februar 2018, 12:20:26
Zitat von: Ranseyer am 06 Februar 2018, 20:30:59
Arnd means ths one: https://github.com/jeelabs/esp-link
I've problem with these software. I've successfully flashed into ESP01 module but I can't get access to device. According documentation https://github.com/jeelabs/esp-link/blob/master/WIFI-CONFIG.md (https://github.com/jeelabs/esp-link/blob/master/WIFI-CONFIG.md) I should see additional (temporary) SSID and configure details of my WiFi networks. Unfortunately I can't see it. I've tried with two ESP01 and one Nodemcu 0.9 modules - the same behavior. Any ideas?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 Februar 2018, 12:41:16
Zitat von: bilbolodz am 09 Februar 2018, 12:20:26
Any ideas?
Do you use black ESP8266-ESP01 modules? They should have enough flash. The non black ones have not enough flash. As an alternative you could try the latest version of ESPEasy and use the serial bridge just for trying, if the problem is soft- or hardware related.
Sometimes also completely erasing flash helped.

Regards Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 09 Februar 2018, 14:36:14
Probably it's "blue one". Are there any "lighter versions"? I need only serial to telnet option.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 Februar 2018, 15:14:11
Probably you can use older ESP version (R120 (http://www.letscontrolit.com/downloads/ESPEasy_R120.zip)) which was also compiled for 512 k memory. See also ESPEasy wiki (https://www.letscontrolit.com/wiki/index.php/Tutorial_ESPEasy_Firmware_Upload#Flash_size).

Kind regards.

Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 09 Februar 2018, 15:19:13
ESPEasy???? Previous post was about esp-link.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 09 Februar 2018, 15:42:15
I do not know, if there is a compiled version of esp-link for 512k modules, for ESPEasy there are. If you choose the serial interface in ESPEasy options, you should get the same result (or at least you can check, if your modules are workung). After that you can search for a smaller esp-link firmware  ;)

Regards Peter

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: bilbolodz am 09 Februar 2018, 16:50:16
OK, I was not aware that ESPEasy has "serial tunneling" option.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 Februar 2018, 17:01:09
ZitatOK, I was not aware that ESPEasy has "serial tunneling" option.

This is correct. But some people believe using ESPeasy is not a really good idea because of security issues...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: hexenmeister am 11 Februar 2018, 23:56:22
Zitat von: Ranseyer am 09 Februar 2018, 17:01:09
This is correct. But some people believe using ESPeasy is not a really good idea because of security issues...
I have looked at ESPEasy code ... security is currently very rudimentary (did not really exist). I hope that will change soon.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 12 Februar 2018, 08:01:43
Hi,
Only for serial ESP-LINK is available:
https://github.com/jeelabs/esp-link/blob/master/FLASHING.md
Kölle Alaaf!
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fhemfreund am 24 Februar 2018, 20:55:21
Frage mal an die Spezialisten: Habe einen MapleCUN aufgebaut (1x 868, 1x 433, 1 HM-MOD-UART) und soweit funktioniert auch alles wie gewünscht ausser:

1) Ich kann auf den HM-MOD-UART nur von einer FHEM Instanz zugreifen - es sieht so aus, also ob keine parallele Zugriffe von 2 FHEM Instanzen via uart://192.168.xxx.xxx:2324 möglich sind.
Ist das so implementiert? (generell ist ja so etwas möglich, z.B. via ESP-Link zu einem ESP8266+HM-MOD-UART)

2) Ich empfange auf meinem 433er CC1101 IT einwandfrei, meine GT_WT_02 Wettersensoren jedoch überhaupt nicht (auch nicht irgendwelche andere in der Nachbarschaft). Auf einer anderen FHEM Instanz werden diese z.B. via Busware CUL einwandfrei empfangen. Sind da ggf. noch spezielle Einstellungen, bzw. Register o.ä. zu setzten?

Andreas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 26 Februar 2018, 19:01:22
Zitat von: fhemfreund am 24 Februar 2018, 20:55:21
1) Ich kann auf den HM-MOD-UART nur von einer FHEM Instanz zugreifen - es sieht so aus, also ob keine parallele Zugriffe von 2 FHEM Instanzen via uart://192.168.xxx.xxx:2324 möglich sind.
Ist das so implementiert? (generell ist ja so etwas möglich, z.B. via ESP-Link zu einem ESP8266+HM-MOD-UART)
Ja, das ist bei der WIZnet Lib so implementiert.

Zitat von: fhemfreund am 24 Februar 2018, 20:55:21
2) Ich empfange auf meinem 433er CC1101 IT einwandfrei, meine GT_WT_02 Wettersensoren jedoch überhaupt nicht (auch nicht irgendwelche andere in der Nachbarschaft). Auf einer anderen FHEM Instanz werden diese z.B. via Busware CUL einwandfrei empfangen. Sind da ggf. noch spezielle Einstellungen, bzw. Register o.ä. zu setzten?
Eigentlich nicht, aber vielleicht hilft es ja, die Register mit "raw e" wieder auf die Defaultwerte zu setzen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: joshi am 28 Februar 2018, 19:48:30
Hallo zusammen,

ich bin gerade dabei ein maplecun zu bauen. Die Basis dafür ist eine V2.1 Platine (groß) von Ranseyer.

Leider wird laut debug kein der 4 CCs erkannt. Hat jemand eine Idee woran das liegen kann. (gibt eine Datenleitung wo ein Kurzschluss oder so zu einem nicht funktionieren von allen anderen CCs führt?)

Lan funktioniert.

Grüße
JoShi
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Februar 2018, 20:25:27
Einfach mal von Pin8 an einem Modul in Richung 1 vorarbeiten. (1-2 sind OK, das sind VCC+GND)

https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: eisman am 29 März 2018, 15:25:03
Hi,

@Ranseyer
wie kann man an eine Platine kommen, würde mich über eine INFO freuen...

gruss

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 29 März 2018, 15:40:52
Das kann man hier nachlesen:
https://forum.fhem.de/index.php/topic,80319.0.html

Z.B. hier gibt es Support zu anderen Features mit denen Telekatz nicht belästigt werden sollte:
https://forum.fhem.de/index.php/topic,81083.msg731620.html#msg731620

Hast ne PN.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Nogga am 29 März 2018, 22:13:37
Ich habe hier den v3 MapleCUN mit 3x868 + 1x433. Gerne würde ich einen der 868er für LaCrosse nutzen.
Was genau muss ich hierfür tun? Die Suchfunktion hier im Forum und Thread hat mich nicht sonderlich schlau gemacht.

Ein set STACKABLE_CC_2 raw Nr1 oder set STACKABLE_CC_2 raw Nr2 hat leider nichts gebracht...

Und noch ein List vom entsprechenden Modul:

Internals:
   CFGFN     
   CMDS       bCAZNELYVWXfz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        STACKABLE_CC_1
   IODev      STACKABLE_CC_1
   NAME       STACKABLE_CC_2
   NOTIFYDEV  STACKABLE_CC_1
   NR         354
   NTFY_ORDER 50-STACKABLE_CC_2
   PARTIAL   
   RAWMSG     02
   RSSI       -73.5
   STACKABLE_CC_2_MSGCNT 43
   STACKABLE_CC_2_TIME 2018-03-29 22:09:59
   STACKED    STACKABLE_CC_3
   STATE      Initialized
   StackLevel 2
   TYPE       STACKABLE_CC
   VERSION    V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_8F (F-Band: 868MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-03-29 22:05:23   cmds             b C A Z N E L Y V W X f z *
     2018-03-29 22:09:59   state           Initialized
Attributes:
   room       STACKABLE_CC
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 30 März 2018, 11:33:24
Es sollte so funktionieren wie hier (https://forum.fhem.de/index.php/topic,36565.0.html) beschrieben, und anscheinend tut es das auch: https://forum.fhem.de/index.php/topic,36565.msg781178.html#msg781178 (https://forum.fhem.de/index.php/topic,36565.msg781178.html#msg781178)

Ich selbst verwende LaCrosse nicht, aber der N Befehl für LaCrosse ist bei allen Transceivern vorhanden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Nogga am 30 März 2018, 13:14:16
Ich bekomme zwar Log-Messages, aber es wird per autocreate leider kein Device angelegt. Bekomme ich denn aus dem Log-Eintrag die Hex-Adresse raus?


2018.03.30 13:03:39 3: set STACKABLE_CC_2 raw Nr1
2018.03.30 13:03:39 3: STACKABLE_CC_2: Unknown code 01, help me!
2018.03.30 13:03:39 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA00002A1011, help me!
2018.03.30 13:03:41 3: STACKABLE_CC_2: Unknown code N019205256A6AAAAA0001058A28, help me!
2018.03.30 13:03:43 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA0000031676, help me!
2018.03.30 13:03:47 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA000025A4D2, help me!
2018.03.30 13:03:51 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA000024D400, help me!
2018.03.30 13:03:54 3: STACKABLE_CC_2: Unknown code N019205256A6AAAAA00001DC528, help me!
2018.03.30 13:03:55 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA00000218CE, help me!
2018.03.30 13:03:59 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA00002C762B, help me!
2018.03.30 13:04:03 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA0000342206, help me!
2018.03.30 13:04:06 3: STACKABLE_CC_2: Unknown code N019205256A6AAAAA0002CD8265, help me!
2018.03.30 13:04:07 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA000005DBA5, help me!
2018.03.30 13:04:10 3: STACKABLE_CC_2: Unknown code N019205256A6AAAAA000006C318, help me!
2018.03.30 13:04:11 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA00003EAD10, help me!
2018.03.30 13:04:15 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA00000C2093, help me!
2018.03.30 13:04:19 3: STACKABLE_CC_2: Unknown code N01902632347FAAAA0000394161, help me!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 05 April 2018, 16:08:36
Ich sehe hier kein LaCrosse-Protokoll, das mitcompiliert wurde:
Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:

https://forum.fhem.de/index.php/topic,36565.msg702474.html#msg702474 (https://forum.fhem.de/index.php/topic,36565.msg702474.html#msg702474)

Z.B.:
Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol

Erfoderlich ist:
#ifdef LACROSSE_HMS_EMU

aber: hier (https://forum.fhem.de/index.php/topic,76615.msg685091.html#msg685091)

2018.04.06 19:11:54 3: set mapleCul raw Nr1
2018.04.06 19:11:54 3: mapleCul: Unknown code 01, help me!


dito: selbes Verhalten:
mapleCul: Unknown code N01767E63E5F0E93C5DCFFF7E79, help me!

Mangels passendem Sensor ... schwer zu testen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 07 April 2018, 17:19:45
@juergs

Beim signalduino kannst du einen String per Dispatch zum Test verarbeiten

Dispatch($defs{SIG868}, "s256FB9006000", undef) }
vielleicht geht das beim cul auch
einfach den String N01767E63E5F0E93C5DCFFF7E79 und den cui eintragen.

Pejonp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 April 2018, 18:06:49
Zitat von: juergs am 05 April 2018, 16:08:36
Ich sehe hier kein LaCrosse-Protokoll, das mitcompiliert wurde:
Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:

https://forum.fhem.de/index.php/topic,36565.msg702474.html#msg702474 (https://forum.fhem.de/index.php/topic,36565.msg702474.html#msg702474)

Z.B.:
Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
Was hier drin steht hängt ja auch nicht davon ab, wie die a-culfw compiliert wurde. Damit da LaCrosse erscheint muss man das CUL Modul in FHEM patchen:
https://forum.fhem.de/index.php/topic,36565.msg591575.html#msg591575 (https://forum.fhem.de/index.php/topic,36565.msg591575.html#msg591575)

Zitat von: juergs am 05 April 2018, 16:08:36
Erfoderlich ist:
#ifdef LACROSSE_HMS_EMU
Anbei eine compilierte Version mit LACROSSE_HMS_EMU. Damit werden dann die LaCrosse Sensoren als HMS Device angelegt. Müllt dir aber immernoch das Log mit "Unknown code N01....." zu.
Meiner Meinung nach ist das Ändern des CUL Moduls die bessere Lösung, da auch bei der a-culfw für CUL und nanoCUL der N Befehl aktiv ist, die LACROSSE_HMS_EMU aus Platzgründen jedoch nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 April 2018, 18:29:04
Hallo Telekatz,

ZitatnanoCUL der N Befehl aktiv ist, die LACROSSE_HMS_EMU aus Platzgründen jedoch nicht.
danke, so hab ich es auch gesehen. Die Platzeinschränkung gilt für den ATmega, sollte aber für den STM32 nicht so relevant sein ...

Danke für den spezifischen Compile ... Die LaCrosse-868MHz-Sensoren scheinen doch sehr attraktiv zu sein.
Den Sensor, den meinCUL empfängt, muß der eines Nachbarn sein  ;)

Ich hatte die aculfw, wie im LaCrosse-Thread schon erwähnt, für den Jeelink compiliert und wollte die Funktionalität mit dem CC1101
auch mal ausprobieren ....

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 07 April 2018, 18:30:52
Zitat von: pejonp am 07 April 2018, 17:19:45
@juergs

Beim signalduino kannst du einen String per Dispatch zum Test verarbeiten

Dispatch($defs{SIG868}, "s256FB9006000", undef) }
vielleicht geht das beim cui auch
einfach den String N01767E63E5F0E93C5DCFFF7E79 und den cui eintragen.

Pejonp

Hallo Pejonp,
ok danke kannte ich noch nicht, schaue ich mir mal mit der neuesten sduino-Version mal an ...  :)

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 12 April 2018, 21:36:07
Hi,

ich habe ein Problem wenn ich 4 Somfy Rolläden auf einmal herunterfahren will.
Im Log sieht man dann:
/dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 disconnected, waiting to reappear (mapleCUL433)

Bewegen tun sich 3 der 4 Rolläden.
Es ist reproduzierbar.

Habt ihr dazu eine Idee?
Läuft da ein Speicher über im Maple CUL?
Hab die Rolläden mal auf den sduino testweise umgestellt, da geht es ohne Probleme.

Hier mal ein Verbose 5 mit dem mapleCUL433.


2018.04.12 21:29:54 4: CUL_Parse: mapleCUL433 YsA4240374080000
2018.04.12 21:29:54 5: mapleCUL433: dispatch YsA4240374080000
2018.04.12 21:29:55 1: /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 disconnected, waiting to reappear (mapleCUL433)
2018.04.12 21:29:57 3: Setting mapleCUL433 serial parameters to 38400,8,N,1
2018.04.12 21:29:58 5: SW: V
2018.04.12 21:29:58 5: CUL/RAW (ReadAnswer): V 1.26.02 a-culfw Build: private build (unknown) MapleCUNx4_03 (F-Band: 868MHz)

2018.04.12 21:29:58 5: SW: ?
2018.04.12 21:29:58 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *

2018.04.12 21:29:58 3: mapleCUL433: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.04.12 21:29:58 5: SW: X21
2018.04.12 21:29:58 5: SW: T01
2018.04.12 21:29:58 5: CUL/RAW (ReadAnswer): 4444

2018.04.12 21:29:58 5: GOT CUL fhtid: 4444
2018.04.12 21:29:58 1: /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 reappeared (mapleCUL433)
2018.04.12 21:29:58 5: SW: *V
2018.04.12 21:29:58 5: SW: *?
2018.04.12 21:29:58 3: STACKABLE_CC_868: Possible commands: bCFiAZNEGMKLUYRTVWXfxz
2018.04.12 21:29:58 5: SW: *X21
2018.04.12 21:29:58 5: SW: *Zr
2018.04.12 21:29:58 5: SW: *Za120777
2018.04.12 21:29:58 5: SW: *Zw111111
2018.04.12 21:30:04 5: mapleCUL433 sending YsAA40039A000007
2018.04.12 21:30:04 5: SW: YsAA40039A000007
2018.04.12 21:30:05 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :AAE9EA70777776:
2018.04.12 21:30:05 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :AAE9EA70777776:
2018.04.12 21:30:05 3: sduino: Unknown code YsAAE9EA70777776, help me!
2018.04.12 21:30:05 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :AA69EA70777776:
2018.04.12 21:30:05 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :AA69EA70777776:
2018.04.12 21:30:05 3: sduino: Unknown code YsAA69EA70777776, help me!
2018.04.12 21:30:05 5: CUL/RAW: /YsAA43039A070000

2018.04.12 21:30:05 4: CUL_Parse: mapleCUL433 YsAA43039A070000
2018.04.12 21:30:05 5: mapleCUL433: dispatch YsAA43039A070000
2018.04.12 21:30:05 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :AAE9EA70777776:
2018.04.12 21:30:05 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :AAE9EA70777776:
2018.04.12 21:30:05 3: sduino: Unknown code YsAAE9EA70777776, help me!
2018.04.12 21:30:06 5: mapleCUL433 sending YsA5400375000008
2018.04.12 21:30:06 5: SW: YsA5400375000008
2018.04.12 21:30:07 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :A5E7E491999998:
2018.04.12 21:30:07 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :A5E7E491999998:
2018.04.12 21:30:07 3: sduino: Unknown code YsA5E7E491999998, help me!
2018.04.12 21:30:07 5: CUL/RAW: /YsA5420375080000

2018.04.12 21:30:07 4: CUL_Parse: mapleCUL433 YsA5420375080000
2018.04.12 21:30:07 5: mapleCUL433: dispatch YsA5420375080000
2018.04.12 21:30:09 5: mapleCUL433 sending YsA9400309000006
2018.04.12 21:30:09 5: SW: YsA9400309000006
2018.04.12 21:30:10 5: CUL/RAW: /YsA94B0309060000

2018.04.12 21:30:10 4: CUL_Parse: mapleCUL433 YsA94B0309060000
2018.04.12 21:30:10 5: mapleCUL433: dispatch YsA94B0309060000
2018.04.12 21:30:10 3: sduino IT: IT_Bewegungsmelder1 2018-04-12 21:30:09->on
2018.04.12 21:30:12 5: mapleCUL433 sending YsAC4003AC000005
2018.04.12 21:30:12 5: SW: YsAC4003AC000005
2018.04.12 21:30:13 5: CUL/RAW: /YsAC4203AC050000

2018.04.12 21:30:13 4: CUL_Parse: mapleCUL433 YsAC4203AC050000
2018.04.12 21:30:13 5: mapleCUL433: dispatch YsAC4203AC050000
2018.04.12 21:30:14 5: mapleCUL433 sending YsA54002C5000004
2018.04.12 21:30:14 5: SW: YsA54002C5000004
2018.04.12 21:30:15 5: CUL/RAW: /YsA54402C5040000

2018.04.12 21:30:15 4: CUL_Parse: mapleCUL433 YsA54402C5040000
2018.04.12 21:30:15 5: mapleCUL433: dispatch YsA54402C5040000
2018.04.12 21:30:17 5: mapleCUL433 sending YsAD4006DD000001
2018.04.12 21:30:17 5: SW: YsAD4006DD000001
2018.04.12 21:30:17 1: FHEMduino_SomfyR No rawDevice set in FHEMduino_SomfyR_000001
2018.04.12 21:30:17 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :ADE9EF32333332:
2018.04.12 21:30:17 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :ADE9EF32333332:
2018.04.12 21:30:17 3: sduino: Unknown code YsADE9EF32333332, help me!
2018.04.12 21:30:17 5: CUL/RAW: /YsAD4406DD010000

2018.04.12 21:30:17 4: CUL_Parse: mapleCUL433 YsAD4406DD010000
2018.04.12 21:30:17 5: mapleCUL433: dispatch YsAD4406DD010000
2018.04.12 21:30:19 5: mapleCUL433 sending YsAB4001FB000003
2018.04.12 21:30:19 5: SW: YsAB4001FB000003
2018.04.12 21:30:19 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :ABE8E912111110:
2018.04.12 21:30:19 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :ABE8E912111110:
2018.04.12 21:30:19 3: sduino: Unknown code YsABE8E912111110, help me!
2018.04.12 21:30:20 5: CUL/RAW: /YsAB4301FB030000

2018.04.12 21:30:20 4: CUL_Parse: mapleCUL433 YsAB4301FB030000
2018.04.12 21:30:20 5: mapleCUL433: dispatch YsAB4301FB030000
2018.04.12 21:30:22 3: sduino IT: IT_Bewegungsmelder1 2018-04-12 21:30:13->on
2018.04.12 21:30:22 5: mapleCUL433 sending YsAD4002BD000002
2018.04.12 21:30:22 5: SW: YsAD4002BD000002
2018.04.12 21:30:23 5: CUL/RAW: /YsAD4502BD020000

2018.04.12 21:30:23 4: CUL_Parse: mapleCUL433 YsAD4502BD020000
2018.04.12 21:30:23 5: mapleCUL433: dispatch YsAD4502BD020000
2018.04.12 21:30:53 5: mapleCUL433 sending YsAD2003AD000005
2018.04.12 21:30:53 5: SW: YsAD2003AD000005
2018.04.12 21:30:53 5: mapleCUL433 sending YsAB20039B000007
2018.04.12 21:30:53 5: SW: YsAB20039B000007
2018.04.12 21:30:53 5: mapleCUL433 sending YsAA20030A000006
2018.04.12 21:30:53 5: SW: YsAA20030A000006
2018.04.12 21:30:53 5: mapleCUL433 sending YsA6200376000008
2018.04.12 21:30:53 5: SW: YsA6200376000008
2018.04.12 21:30:54 5: CUL/RAW: /YsAD2403AD050000

2018.04.12 21:30:54 4: CUL_Parse: mapleCUL433 YsAD2403AD050000
2018.04.12 21:30:54 5: mapleCUL433: dispatch YsAD2403AD050000
2018.04.12 21:30:54 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :AB8E8D16111110:
2018.04.12 21:30:54 1: sduino: SOMFY_Parse : Somfy RTS checksum error! :AB8E8D16111110:
2018.04.12 21:30:54 3: sduino: Unknown code YsAB8E8D16111110, help me!
2018.04.12 21:30:54 5: CUL/RAW: /YsAB25039B070000

2018.04.12 21:30:54 4: CUL_Parse: mapleCUL433 YsAB25039B070000
2018.04.12 21:30:54 5: mapleCUL433: dispatch YsAB25039B070000
2018.04.12 21:30:55 1: /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 disconnected, waiting to reappear (mapleCUL433)
2018.04.12 21:30:58 3: Setting mapleCUL433 serial parameters to 38400,8,N,1
2018.04.12 21:30:58 5: SW: V
2018.04.12 21:30:58 5: CUL/RAW (ReadAnswer): V 1.26.02 a-culfw Build: private build (unknown) MapleCUNx4_03 (F-Band: 868MHz)

2018.04.12 21:30:58 5: SW: ?
2018.04.12 21:30:58 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *

2018.04.12 21:30:58 3: mapleCUL433: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.04.12 21:30:58 5: SW: X21
2018.04.12 21:30:58 5: SW: T01
2018.04.12 21:30:58 5: CUL/RAW (ReadAnswer): 4444

2018.04.12 21:30:58 5: GOT CUL fhtid: 4444
2018.04.12 21:30:58 1: /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 reappeared (mapleCUL433)
2018.04.12 21:30:58 5: SW: *V
2018.04.12 21:30:58 5: SW: *?
2018.04.12 21:30:58 3: STACKABLE_CC_868: Possible commands: bCFiAZNEGMKLUYRTVWXfxz
2018.04.12 21:30:58 5: SW: *X21
2018.04.12 21:30:58 5: SW: *Zr
2018.04.12 21:30:58 5: SW: *Za120777
2018.04.12 21:30:58 5: SW: *Zw111111


Gruß und vielen Dank,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: mark79 am 03 Mai 2018, 11:34:55
Hallo,

ich habe mir von Ranseyer ein Maple Small zuschicken lassen und er hat mir 2 Stück STM32 Gratis beigelegt, aber hat da schon erwähnt das wären Drecksdinger. :D

Ich bekomme auf diese Maple Mini STM32 Maple USB keinen Bootloader geflasht, wie unten der PeMue... Habe das genau so angeschlossen wie er:
RX1 > TX UART
TX1 > RX UART
GND > GND UART
3,3V > 3,3V UART (auch per USB Stromversorgung probiert)
BOOT1 > GND (STM32)

Ich habe 2 verschiedene UARTs (FTL & CH340) ausprobiert auf 3 verschiedenen Rechnern, 2x Windows und 1x Linux und erhalte auch immer diesen Fehler: "Failed to init device."

Auch das Flash Script von Ranseyer habe ich ausprobiert, so das der Flash Vorgang immer im loop stattfindet... BUT32 Taste gedrückt halten, dann erst Saft auf den STM32 geben und dann die BUT32 Taste los lassen. Habe das an die 10 mal probiert, aber das will einfach nicht funktionieren.  :(

Hat jemand eine Lösung, wie man diese Teile dennoch flashen kann? Ein Foto davon befindet sich im Anhang.

Zitat von: PeMue am 15 Juni 2017, 08:04:25
Hallo zusammen,

ich schaffe es irgendwie nicht, den Bootloader zu brennen:
- USB2seriell Wandler ist angeschlossen (Rx<->Tx, Tx<->Rx, GND verbunden), die Kreuzung habe ich dreimal geprüft
- ich habe auf dem Raspberry Pi stm32flash heruntergeladen und compiliert
- USB2seriell an USB Anschluss des Raspberries (mappt auf /dev/ttyUSB2), Spannung an den maple Mini
- but 32 gedrückt + gehalten, reset gedrückt, beide Tasten losgelassen, die blinkende blaue LED hört auf zu blinken
stm32flash /dev/ttyUSB2 sagt

stm32flash 0.5
http://stm32flash.sourceforge.net/
Interface serial_posix: 57600 8E1
Failed to init device.

Dasselbe mit einem anderen maple Mini bzw. auch mit BOOT1 auf GND gezogen. Irgendwo ist noch
ein prinzipieller Fehler, den ich aber gerade nicht sehe  :-\

Nebenbei: Wenn ich den Bootloader draufbrenne, und den USB2Seriell Adapter angeschlossen habe, könnte ich ja auf gleiche Weise die MapleCUNx4_W5100_BL.bin draufbrennen, oder? Oder muss die zwingend per USB geflasht werden?

Danke für Eure Hinweise.


Viele Grüße
Mark
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 03 Mai 2018, 13:32:23
Ich kennen es so: Spannung drauf und alles anschließen zum flashen (auch die Brücke BOOT1 <-> GND).
Dann BUT32 und RESET gleichzeitig drückt.
Nun nur RESET los lassen und nach ca. 2sec BUT32 los lassen.
Dann sollte man problemlos den Bootloader flashen können.

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: mark79 am 03 Mai 2018, 13:35:36
Ich habe es jetzt wohl doch hinbekommen, ich habe andere Anschlüsse am Maple ausprobiert wie hier beschrieben: https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/stm32duino-bootloader
Hat aber auch nicht geklappt, dann hatte ich den UART auf 23(dp) 24(da) gesetzt, ging auch nicht und dann wieder zurück 25(rx1) und 26(tx1) und dann konnte ich den Bootloader komischerweise flashen.

Musste ihn vorher allerdings noch mit stm32flash.exe -k den flash löschen...

c:\esp\stm32>stm32flash.exe -w maple_mini_boot20.bin COM11
stm32flash 0.5

http://stm32flash.sourceforge.net/

Using Parser : Raw BINARY
Interface serial_w32: 57600 8E1
Version      : 0x22
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0410 (STM32F10xxx Medium-density)
- RAM        : 20KiB  (512b reserved by bootloader)
- Flash      : 128KiB (size first sector: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Wrote address 0x0800501c (100.00%) Done.


c:\esp\stm32\dfu-util-0.9-win64>dfu-util.exe --verbose --device 1eaf:0003 --cfg1 --alt 2 --download MapleCUNx4_W5500_BL.bin
dfu-util 0.9

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [======================== ]  97%        65536 bytesError sending
completion packet
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 Juni 2018, 13:16:17
Ich habe gerade mal zwei Stück gebaut. Den Bootloader habe erst nach dem Einlöten des LAN Moduls (W5500) versucht zu flaschen.
Das ist mir nicht so richtig logisch denn das LAN Modul hängt doch an normalen I/O Ports.
Das Flashen des Bootloader über den Debug-Port startet entweder gar nicht, oder bricht nach 20,30 oder 50% ab...


Aber wenn ich das LAN Modul auslöte dann lässt sich der Bootloader flashen. Was übersehe ich da ?
((Und mit dem Auslöten welches möglichst einzelnen Pins lässt sich das umgehen))
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 02 Juni 2018, 19:35:08
Da die Pins des W5500 nichts mit dem Bootloader zu tun haben, würde ich mal auf eine schlechte Stromversorgung tippen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 03 Juni 2018, 13:46:50
Wenn man es richtig macht, dass funktioniert es auch spontan.
Danke fürs führen aus dem Walde...


PS: Ich hab jetzt schon ein paar gebaut und lustigerweise schon wieder eine Idee zum Verbessern (schon vor diesem Thema hatte ich vor eine Holhbuchse vorzusehen, weil einige der Mini USB-Buchsen Kummer machen, und außerdem sind diese recht unpraktisch...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 17 Juni 2018, 23:33:12
Hi,

hab da mal eine Frage zur aktuellen a-culfw und dem MapleCUN. Gibt die a-culfw irgendwie noch die Debug Ausgabe am Debug Port aus? Wenn Ja was muss ich denn tun damit sie dies tut. Ich habe mit einem MapleCUN das Problem das scheinbar die W5500 nicht erkannt wird. Den Durchgang der Pins habe ich schon geprüft und den W5500 hab ich auch schon mal getauscht ohne erfolg. Wollte mal nachsehen ob da eine Ausgabe kommt was ja früher auch ging. Da konnt man ja auch sehen ob alle CC1101 erkannt wurden und so.

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Juni 2018, 09:34:48
Die Debugausgabe am Debug UART ist mit der Version 1.26.02 weggefallen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 18 Juni 2018, 10:00:14
Daher flashe ich zum Test immer die alte. (Alternative wäre selbst kompilieren und aktivieren was man möchte)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 18 Juni 2018, 17:36:00
Sehe ich das richtig das ich #define HAS_UART nur in der boards.h auskommentieren muss um die Debugausgaben wieder zu aktivieren?

LG Alina

Edit: Beantworte mir mal selbst. Ja damit geht die Debugausgabe wieder.

Ich bekommen folgendes angezeigt:

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Jun 18 2018 18:09:02 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x18
-I- Detected CC2: PN 0x00  VER 0x14
-I- Detected CC3: PN 0x00  VER 0x14
-I- Not detected ethernet
-I- Not detected onewire
-I- init USB
-I- init Complete

Wenn ich den MapleCUN resete geht auch kurz die Link lampe an der Buchse aus also irgendwas scheint er mit dem W5500 zu machen.

Kann mir jemand sagen was die Ausgaben "WIZCHIP Initialized success." und "-I- Not detected ethernet" genau bedeuten?

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Juni 2018, 18:41:01
"WIZCHIP Initialized success." ist eine Ausgabe der Wizchip Lib und der ist es egal, ob ein W5500 angeschlossen ist oder nicht. Die Ausgabe kommt beim aufrufen der Init Funktion immer. Eine Prüfung findet hier nicht statt.

Erst später wird geprüft, ob der W5500 auch ansprechbar ist, was hier nicht der Fall ist und mit "-I- Not detected ethernet" ausgegeben wird.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fuppking am 09 Juli 2018, 16:11:14
Hallo hab ein Grundlegendes Problem. Hab bis jetzt nur Arduinos benutzt. Versuche gerade einen MapleCun zu flaschen. Ich hab den Bootloader draufgespielt (zumindest glaub ich das). Es wird im Gerätemanager eine Serieller Usb (com3) erkannt. Was vorher nicht war. Laut Anleitung soll ich mit dfu-util die a-culfw draufflashen. Genau da ist mein Problem.
Laut Anleitung muss ich auf den Reset Knopf drücken und loslassen die Led blink für ca 2 Sek schnell. Dann ist schluss mit blinken. (ist das eigenloich so richtig) Den Bootloader zu flashen hat 3 sek. gedauert? ist das realistisch?g
Gibt es eine andere Software zum draufflashen der a-culfw auf den Maple?

Ich währe für jede Hilfe dankbar

lg
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 09 Juli 2018, 20:40:37
Drück unmittelbar nach dem loslassen des Resetknopfes die but=32 Taste. Dann bleibt er länger als 2 Sekunden im Bootloader Modus und du hast genügend Zeit mit dem dfu-util.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: fuppking am 10 Juli 2018, 21:32:38
Super danke dafür guter Tipp...

das dfu-util finden das Device nicht. Das geräte wird erkann im GeräteManager als
Maple 003 (wenn die LED im 4khz takt blinkt) als Andere Geräte.
wenn ich ihn nicht im bootmodus halte sonder gleich durchstarten lasse wird er
als SerielerUSB (com3) erkannt.
muss ich hier noch einen Treiber installieren ???

dfu-util --verbose --device Maple 003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: mgarms am 15 Juli 2018, 13:40:54
Ich selber habe mich jetzt an dem MapleCun versucht und ihn erst zusammengelötet. Mit dem W5500 war kein flashen mehr möglich. Beim entlöten habe ich dann scheinbar die Pads abgerissen und ihn immer noch nicht rausbekommen. Und das trotz Entötpumpe und Entlötlitze. Ich habe ihn jetzt etwas brachialer entfernt. Falls noch jemand einen W5500 zu Chinapreisen hat, würde ich ihn nehmen. Da wäre vielleicht auch ein Hinweis gut.

Das flashen funktioniert bei mir nur mit dem Boot1 Pin auf GND und dem Boot0 Pin auf VCC. Die Methode aus der Anleitung(but=32 und reset button) brachte bei mir keinen Erfolg. Auch funktinierten die herausgeführten Uarts nicht zum Flashen. Ich musste direkt auf das Board gehen.

Meine Frage ist allerdings. Ist der Debug Uart ganz normal der Tx1/RX1 auf dem Maple Mini?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Juli 2018, 14:01:04
Wenn es um meine Platine gehen sollte:

ZitatIst der Debug Uart ganz normal der Tx*/RX* auf dem Maple Mini?
Ja.

ZitatDa wäre vielleicht auch ein Hinweis gut.
Wenn die Spannung ausreichend stabil ist, flasht das Teil auch. (Ist mir selbst kürzlich mal passiert dein Problem)
Im Prinzip kannst Du dich freuen wenn es in dem Fall nicht flasht, der CUL würde auch nicht 100% stabil laufen. (Am Eingang müssen 5,0V zu messen sein, mein schlechtestes bringt bei minimaler Last nur noch 4,3V und das reicht eben nicht mehr für den Spannnungsregler am MAPLE.

Du kannst gerne das Wiki editieren...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: mgarms am 15 Juli 2018, 14:35:20
Zitat von: Ranseyer am 15 Juli 2018, 14:01:04
Wenn es um meine Platine gehen sollte:
Ja.

Ja ist deine Platine. Wie gesagt auch mit den UART0 und UART1 auf deiner Platine hatte ich keinen Erfolg. Vielleicht habe ich mistig gelötet. Aber die Lötpunkte sehen eigentlich gut aus. Das heißt ich gehe direkt an den Maple.

Zitat von: Ranseyer am 15 Juli 2018, 14:01:04
Wenn die Spannung ausreichend stabil ist, flasht das Teil auch. (Ist mir selbst kürzlich mal passiert dein Problem)
Im Prinzip kannst Du dich freuen wenn es in dem Fall nicht flasht, der CUL würde auch nicht 100% stabil laufen. (Am Eingang müssen 5,0V zu messen sein, mein schlechtestes bringt bei minimaler Last nur noch 4,3V und das reicht eben nicht mehr für den Spannnungsregler am MAPLE.

Ich habe verschiedene Methoden versucht:
-Mit aktivem USB HUB und ohne(gemixt) mit verschiedenen Kabeln.
-4 verschiedene Rechner

Nichts führte zum Erfolg. Auch direkt an den Pins des Maple( nach dem Spannungswandler) funktioniert es nicht. Als der W5500 dann runter war, funktionierte es direkt an den Pins des Maple wunderbar.

Ich kann natürlich nicht ausschließen, dass ich mistig gelötet habe. Ungeübt muss man da schon ein bisschen kämpfen.

Sind nur meine Erfahrungen. Vielleicht hilft es jemand anderes.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Juli 2018, 14:57:36
Ich flashe immer am Debug Port der Platine. Natürlich ist RX+TX zu kreuzen als ggf einfach mal tauschen.

Dann stelle ich mich dumm und starte einfach mein Skript Nr.1 siehe Anlage. Das sagt mir was ich tun soll:
-"but" gedrückt halten
-während-dessen das USB Kabel am Maple einstecken


(Es es gibt viele Wege nach Rom)

PS: Bei so nem Projekt muss jeder selbst wissen was er sich zutraut. Ich gehe so vor:
-MAPLE (nur von Bate) und Stamps verlöten, und vorletzte Firmware flashen und schauen ob alle Stamps erkannt werden. Das klappt eiegentlich immer, und Kurzschlüsse habe ich bei manuellem Verlöten keine. (mit Lötpaste ggf schon)
-Das LAN Modul teste ich immer vor dem verlöten. Dazu braucht man z.B. einen MAPLE-CUL mit steckplatz für das LAN Modul.
Auf dem Tisch liegen schon ein paar Defekte:
  -LAN geht nicht (z.B. Link-LED bleibt dunkel): Anschlüsse zur RJ45 Buchse nachlöten: 100% der Fehler behoben
  -Kurzschluss zwischen VCC und GND beim LAN Modul: Keine Ahnung warum, auch nicht wirklich gesucht...
  -LAN Modul wird vom Maple nicht erkannt (div Gründe möglich)

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: mgarms am 15 Juli 2018, 19:01:47
Zitat von: Ranseyer am 15 Juli 2018, 14:57:36

PS: Bei so nem Projekt muss jeder selbst wissen was er sich zutraut. Ich gehe so vor:
-MAPLE (nur von Bate) und Stamps verlöten, und vorletzte Firmware flashen und schauen ob alle Stamps erkannt werden. Das klappt eiegentlich immer, und Kurzschlüsse habe ich bei manuellem Verlöten keine. (mit Lötpaste ggf schon)
-Das LAN Modul teste ich immer vor dem verlöten. Dazu braucht man z.B. einen MAPLE-CUL mit steckplatz für das LAN Modul.
Auf dem Tisch liegen schon ein paar Defekte:
  -LAN geht nicht (z.B. Link-LED bleibt dunkel): Anschlüsse zur RJ45 Buchse nachlöten: 100% der Fehler behoben
  -Kurzschluss zwischen VCC und GND beim LAN Modul: Keine Ahnung warum, auch nicht wirklich gesucht...
  -LAN Modul wird vom Maple nicht erkannt (div Gründe möglich)

Hinterher ist man immer klüger. Ich ärger mich auch ein bisschen,dass ich nicht einfach abwarten konnte bis alle Bauteile da sind.

Hast du einen guten Tip wie man die CC1101 gut Löten kann? Also die Platte ohne Pins. Ich fand dies mit dem Lötkolben und meiner kleinen Spitze schon friemelig. Allerdings war ich so Klug erst Maple und W5500 zu löten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Juli 2018, 19:16:59
Zitatwie man die CC1101 gut Löten kann? Also die Platte ohne Pins.
-zuerst auf der Basisplatine auf den Platz für den Antennenausgang (Mitte der drei Pins) einen Tropfen Zinn. Die Stamp drauflegen  und verlöten inkl. Ausrichten.
-ggf auch gleich den mittleren Anschluss der SMA Buchse leicht verzinnen, so dass die Buchse nach Aufstecken hält.
-Flussmittel auf die 8 Pins der anderen Seite und mit viel Zinn darüber löten, z.B. auch so dass 2 oder gar 3 Pins auf einmal gelötet werden, wenn das Flussmittel / Lötstopmaske passt gibt es keine Kurzschlüsse,
bzw. wenn das Zinn noch frisch ist und nicht irgendwie zerbrutzelt durch langes Löten an der Luft kann man es bei Bedarf mit Hilfe der Schwerkraft wieder wegnehmen wenn die Antennenseite leit nach oben zeigt.

Wenn das LAN Modul schon verbaut ist macht die erste Stamp weniger Spass und erfordert mehr Konzentration.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: davedeluxe am 27 Juli 2018, 08:18:22
Hi,


kann ich auf dem MapleCUN auch die Firmware von Ansgar nutzen?
https://forum.fhem.de/index.php/topic,24436.0.html

Hat das jemand mal getestet?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 28 Juli 2018, 14:33:46
Nein, geht nicht. Von der TSCUL Firmware gibt es keine STM32 Version.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 16 August 2018, 21:16:41
Hi,

habe mal ne Frage zum Maple CUL.
Wenn ich meine Somfy Rolläden (6 Stück) fahre, rebooted er nach 3 Kommandos. Somit schafft er es 3 Rollos zu schließen, die anderen 3 gehen verloren wegen dem Reboot:

2018.08.16 20:55:44 1: /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 disconnected, waiting to reappear (mapleCUL433)
2018.08.16 20:55:47 3: Setting mapleCUL433 serial parameters to 38400,8,N,1
2018.08.16 20:55:47 3: mapleCUL433: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.08.16 20:55:47 1: /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00 reappeared (mapleCUL433)
2018.08.16 20:55:47 3: mapleCUL433_CC_868: Possible commands: bCFiAZNEGMKLUYRTVWXfxz


Baue ich pausen zwischen die Kommandos geht es relativ zuverlässig.
Blöd wird es wieder wenn ich nur beschatten will. Dann muss er für Somfy ein Start Signal zum Fahren Senden und eine gewisse Zeit später ein Stop. Das macht ein Abstürzen wieder wahrscheinlicher.
Ist es bekannt das der MapleCUL mit gleichzeitigen Kommandos, bzw fast gleichzeitigen Kommandos ein Problem hat und sich rebooted? Eventuell nur in zusammenspiel mit Somfy?

Habe das selbe mit dem Signalduino probiert. Dort gab es kein Problem.

Hier noch ein List vom Maple Cul:


Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::OREGON::Hideki:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00@38400 4444
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_3546e60a-if00@38400
   FD         45
   FHTID      4444
   NAME       mapleCUL433
   NR         80
   PARTIAL   
   RAWMSG     *SDC3EF1011E000136270001000000007532
   RSSI       -83.5
   STACKED    mapleCUL433_CC_868
   STATE      Initialized
   TIME       1534446030.69025
   TYPE       CUL
   VERSION    V 1.26.03 a-culfw Build: private build (unknown) MapleCUNx4_03 (F-Band: 433MHz)
   initString X21
   mapleCUL433_MSGCNT 12494
   mapleCUL433_TIME 2018-08-16 21:15:50
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-08-12 18:49:57   ccconf          freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB
     2018-08-16 20:55:47   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2018-08-16 21:15:50   state           Initialized
Attributes:
   icon       cul_cul
   room       Devices
   sortby     1


Vielen Dank und viele Grüße,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 17 August 2018, 03:53:12
Ist die Spannung am USB Port auch zu 100% stabil bei 5,000 Volt? Wenn darunter, hätte ich auch massiv Kummer...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 17 August 2018, 11:39:53
Setz mal wie hier erwähnt die Anzahl der Wiederholungen herunter: https://forum.fhem.de/index.php/topic,24158.msg360746.html#msg360746 (https://forum.fhem.de/index.php/topic,24158.msg360746.html#msg360746)
Eventuell dauert das Senden eines Kommandos zu lange, so das der Watchdog auslöst.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 17 August 2018, 12:35:02
Hi, danke.
Spannung schließe ich mal aus. Habe ihn an einem Raspberry mit Rapberry Netzteil 5,1V.
Das mit den Wiederholungen Probiere ich aus. Klingt gut.

Danke und Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 19 August 2018, 17:58:18
Das gleiche Problem mit dem Reboot habe ich auch. Allerdings hängt mein CUN an einer VM einer Synology. Ich dachte erst, das die Synology den CUN sporadisch rausschmeißt bis ich darauf gestoßen bin, dass es jedesmal nach dem Somfy senden passiert. Das hat leider ein ganzes Wochenende gedauert. Der Beitrag weiter oben bestätigt jetzt die Beobachtung.
Als Zwischenlösung habe ich jetzt erst einmal ein sleep zwischen den einzelnen set somfy eingebaut. Nicht sehr elegant aber der CUN schmiert nicht mehr ab.

Mit der Wiederholungen werde ich gleich mal ausprobieren.

Edit:
Spannung hatte ich auch gedacht und habe einen aktive USB-Hub dazwischen geschaltet. Gleiches Verhalten.

Nach wieviel Millisekunden wird den der Watchdog ausgelößt? Damit man mal ein Gefühl für die ,,repetitions" bekommt die eingestellt werden sollten. Im Schnitt bin ich bei 3.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 19 August 2018, 21:33:36
Ungefüttert löst der Watchdog nach etwa 2 Sekunden aus.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 20 August 2018, 07:30:33
Bin dann gestern doch nicht mehr zum testen gekommen, aber zwei Sekunden ist schon recht lang. Bei einem Somfy Gerät hatte ich die repetition nicht eingestellt. Möglich das genau das Device der Trigger für den Neustart war.

Ungefüttert entnehme ich, dass man den WatchDog auch ändern kann. Wenn ja wie?
Und noch eine Frage. Würde man den im FHEM Log mit verbose 5 den WatchDog als Trigger für den Neustart des CUN sehen.

Was mich noch ein wenig irritiert, dass es mit dem CUL von Busware und der Standard FW mit der gleichen fhem.cfg ohne Probleme lief.

Ich habe jetzt erst mal einen W5500 Netzwerkadapter bestellt. Damit habe ich das Problem nicht mehr, dass der CUN aus der VM geworfen wird und ich in händisch wieder reinhängen muß.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 21 August 2018, 23:08:01
Hi,

ich habe gerade das neue Gehäuse für Ranseyer sein CUN-STM32 Large V2.1 auf Thingiverse veröffentlicht.
Link: https://www.thingiverse.com/thing:3061192

Das Gehäuse ist nun etwas flacher und kürzer. Es hält mit Häkchen zusammen statt mit Schrauben.

Viel Spass damit

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 22 August 2018, 15:16:32
Woran kann es liegen, das die 868MHZ die Empfangsleistung gleich Null ist? Die HM Aktoren kann ich schalten bekomme aber keine Rückmeldung. Fensterkontakte und Bewegungsmelder melden sich gar nicht mehr.

Hier mal ein List vom CUN_0

CMDS       
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_cf5a56e2-if00@42 1235
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_cf5a56e2-if00@42
   FHTID      1235
   NAME       MapleCUL_0
   NR         398
   PARTIAL   
   STATE      disconnected
   TYPE       CUL
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-08-21 18:07:24   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:42dB sens:4dB
     2018-08-21 18:07:11   cmds            B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2018-08-21 18:04:15   raw             No answer
     2018-08-22 07:25:52   state           disconnected
   helper:
Attributes:
   DbLogInclude state
   alias      CUL_0 868.00 MHz
   event-on-change-reading state
   hmId       F11234
   icon       cul_usb
   room       SYSTEM
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: blueicechip am 22 August 2018, 19:18:32
Ich sehen bei dir state :  disconnected  und damit  du auch empfangen kannst, sollte der rfmode doch normalerweise auf Homematik stehen.

Welchen Mappe hast du denn  ? Und welche Firmware ? Ich sehen bei dir auch nichts von wegen stackable.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 22 August 2018, 21:37:35
Ja der CUN ist disconnected weil er ja nicht mehr dran steckt. Es muss ja irgendwie weiter gehen. rfmode HomeMatic hatte ich auch eingestellt. Keine Verbesserung.

Was meinst Du mit Mappe? Die FW ist a-culfw 1.25.

Ich schließe den CUN morgen noch mal und mache dann ein erneutes List. Heute bin ich nicht vor Ort.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: blueicechip am 22 August 2018, 22:30:15
Ups,
ich meinte: Welche Maple Hardware hast du ?  Laut deinem footer hast den nen CUN(etwork) mit drei Transceivern -  in welcher Reihenfolge sind die Bestückt  ? damit auch die stackable Zuordnung passt.
Und an der Firmware hat sich auch einiges getan.

Bei mit sind 4 Transceiver (868/868/433/868) drauf und auf cc4 laufen die MAX(eq3) seit Monaten stabile.

ZitatInternals:
   CMDS       CAZNELYVXfz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        MapleCUN3
   IODev      MapleCUN3
   MapleCUN4_MSGCNT 23
   MapleCUN4_TIME 2018-08-22 22:02:34
   NAME       MapleCUN4
   NOTIFYDEV  MapleCUN3
   NR         93
   NTFY_ORDER 50-MapleCUN4
   PARTIAL   
   RAWMSG     Z0B03063017880812345600100D
   RSSI       -67.5
   STATE      Initialized
   StackLevel 3
   TYPE       STACKABLE_CC
   VERSION    V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) MapleCUNx4_8F (F-Band: 868MHz)
   initString X21
Zr
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-08-22 20:46:41   cmds             C A Z N E L Y V X f z
     2018-08-22 21:47:11   credit10ms      3600
     2018-08-22 22:02:34   state           Initialized
Attributes:
   icon       it_wifi
   model      CUN
   rfmode     MAX
   room       System/quote]/td]
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 23 August 2018, 08:21:22
Ich benutze die Maple Hardware von Ranseyer. Nicht als Netzwerkvariante, sondern als USB. Mein Fehler. Soll aber noch ins Netzwerk. Der W5500 ist bestellt.
Es sind drei Receiver verbaut 868(CC0) / 433(CC1) / 433(CC2)

So. Ich habe den MapleCUL jetzt noch mal rein gehangen.

Internals:
   CHANGED   
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_cf5a56e2-if00@42 1235
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_cf5a56e2-if00@42
   FD         16
   FHTID      1235
   MapleCUL_0_MSGCNT 3
   MapleCUL_0_TIME 2018-08-23 08:10:39
   NAME       MapleCUL_0
   NR         398
   PARTIAL   
   RAWMSG     **omB612DBACD42AF7
   STACKED    MapleCUL_0_SCC
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_07 (F-Band: 868MHz)
   initString X21
Ar
   Helper:
     DBLOG:
       state:
         DbLog:
           TIME       1535004349.8897
           VALUE      CONNECTED
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-08-23 08:11:17   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-08-23 08:05:49   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2018-08-21 18:04:15   raw             No answer
     2018-08-23 08:10:39   state           Initialized
   helper:
Attributes:
   DbLogInclude state
   event-on-change-reading state
   hmId       F11234
   icon       cul_usb
   rfmode     HomeMatic
   room       SYSTEM
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: blueicechip am 23 August 2018, 17:56:57

RAWMSG     **omB612DBACD42AF7


Der scheint ja auf CC2 ( siehe 2  x "*") schon mal was zu Empfangen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 24 August 2018, 11:18:55
Ok. Wie kann das bei meinem Problem weiterhelfen?
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 24 August 2018, 16:41:33
Hi,
Das bedeutet er ist nicht taub, sondern der cc2 also 3te Empfänger hört sehr wohl etwas. Deine Einrichtung ist uns aber immer nich nicht klar!
Zeig mal ein

list TYPE=CUL
list TYPE=STACKABLE
list TYPE=STACKABLE_CC

Hast Du nach Anleitung im Wiki https://wiki.fhem.de/wiki/MapleCUN die weiteren CULs als Stackable_CC oder als Stackable eingerichtet. Zeig mal alle list der Geräte die oben angezeigt werden ;-)
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 25 August 2018, 11:30:56
Ich musste erst einmal den MapleCUL in mein Testsystem hängen. Jetzt kann ich besser rumspielen.

Eingerichtet habe ich den Maple wie in der Wiki unter "Einrichtung in FHEM (neu) ; Beispiel 2" beschrieben. Auch auf dem Testsystem zeigt er das gleiche Verhalten. Senden geht Empfang gleich Null.

Hier mal die List der Geräte:
list TYPE=CUL

mapleCUL_0
mapleCUL_1
mapleCUL_2


list TYPE=STACKABLE

mapleCUL_0Stack
mapleCUL_1Stack


list mapleCUL_0

Internals:
   CFGFN     
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_cf5a56e2-if00@38400 2411
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_cf5a56e2-if00@38400
   FD         17
   FHTID      2411
   NAME       mapleCUL_0
   NR         106
   NR_CMD_LAST_H 4
   PARTIAL   
   RAWMSG     **omA9B599585730F5
   RSSI       -77.5
   STACKED    mapleCUL_0Stack
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_07 (F-Band: 868MHz)
   initString X21
   mapleCUL_0_MSGCNT 7
   mapleCUL_0_TIME 2018-08-25 11:27:18
   mapleCUL_MSGCNT 1
   mapleCUL_TIME 2018-08-25 11:01:24
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-08-25 11:27:37   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:42dB sens:8dB
     2018-08-25 11:05:00   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2018-08-25 11:27:18   state           Initialized
   XMIT_TIME:
     1535188636.62612
     1535188640.25799
     1535188644.81031
     1535188650.08467
   helper:
     5F6C25:
       QUEUE:
Attributes:
   hmId       F12411
   model      CUL
   rfmode     HomeMatic
   room       CUL


list mapleCUL_1
Internals:
   CFGFN     
   CMDS       bCFiAZNEGMKLUYRTVWXfz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        FHEM:DEVIO:mapleCUL_0Stack:9600 0000
   DeviceName FHEM:DEVIO:mapleCUL_0Stack:9600
   FD         17
   FHTID      0000
   IODev      mapleCUL_0Stack
   IODevPort  9600
   IODevRxBuffer
   IOReadFn   STACKABLE_IOReadFn
   NAME       mapleCUL_1
   NR         126
   PARTIAL   
   RAWMSG     *omA9B599585730F5
   STACKED    mapleCUL_1Stack
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_07 (F-Band: 433MHz)
   initString X21
   mapleCUL_1_MSGCNT 5
   mapleCUL_1_TIME 2018-08-25 11:27:18
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-08-25 11:27:43   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-08-25 11:10:01   cmds             b C F i A Z N E G M K L U Y R T V W X f z *
     2018-08-25 11:27:18   state           Initialized
Attributes:
   model      CUL
   rfmode     SlowRF
   room       CUL


list mapleCUL_2
Internals:
   CFGFN     
   CMDS       bCAZNELYVWXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        FHEM:DEVIO:mapleCUL_1Stack:9600 0000
   DeviceName FHEM:DEVIO:mapleCUL_1Stack:9600
   FD         17
   FHTID      0000
   IODev      mapleCUL_1Stack
   IODevPort  9600
   IODevRxBuffer
   IOReadFn   STACKABLE_IOReadFn
   NAME       mapleCUL_2
   NR         146
   PARTIAL   
   RAWMSG     omA9B599585730F5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_07 (F-Band: 433MHz)
   initString X21
   mapleCUL_2_MSGCNT 5
   mapleCUL_2_TIME 2018-08-25 11:27:18
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-08-25 11:27:49   ccconf          freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-08-25 11:12:06   cmds             b C A Z N E L Y V W X f z
     2018-08-25 11:27:18   state           Initialized
Attributes:
   model      CUL
   rfmode     SlowRF
   room       CUL


list mapleCUL_0Stack
Internals:
   CFGFN     
   DEF        mapleCUL_0
   IODev      mapleCUL_0
   NAME       mapleCUL_0Stack
   NOTIFYDEV  mapleCUL_0
   NR         119
   NTFY_ORDER 50-mapleCUL_0Stack
   STATE      Defined
   TYPE       STACKABLE
Attributes:
   room       CUL


list mapleCUL_1Stack
Internals:
   CFGFN     
   DEF        mapleCUL_1
   IODev      mapleCUL_1
   NAME       mapleCUL_1Stack
   NOTIFYDEV  mapleCUL_1
   NR         134
   NTFY_ORDER 50-mapleCUL_1Stack
   STATE      Defined
   TYPE       STACKABLE
Attributes:
   room       CUL

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 25 August 2018, 14:13:02
Okay, ich weiss es klingt blöd, aber definiere mal wie die alte Methode es beschreibt und boote Dein Testsystem danach neu. Hintergrund: Mir ist keiner bekannt, der die neue Methode bei normalen CULs nutzt. Nur bei den Tests mit ZWave hat Rudi und ein weiterer Kollege das mal getan. Meine Tests jedenfalls hatte ich mit Empfangsprobleme abgebrochen ;-)

Dann berichte mal!

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 25 August 2018, 16:01:26
Ich wer blede! Das Geht!  ;)

Das war der richtige Hinweiß. Funktioniert wie es soll.

Der Vollständigkeit halber hier noch meine Definition für den mapleCul.

defmod CUL0 CUL /dev/ttyACM0@38400 2411
attr CUL0 rfmode HomeMatic
attr CUL0 room CUL

defmod CUL1 STACKABLE_CC CUL0
attr CUL1 rfmode SlowRF
attr CUL1 room CUL

defmod CUL2 STACKABLE_CC CUL1
attr CUL2 rfmode SlowRF
attr CUL2 room CUL
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 25 August 2018, 16:43:35
Zitat von: RaspiLED am 25 August 2018, 14:13:02
Okay, ich weiss es klingt blöd, aber definiere mal wie die alte Methode es beschreibt und boote Dein Testsystem danach neu. Hintergrund: Mir ist keiner bekannt, der die neue Methode bei normalen CULs nutzt. Nur bei den Tests mit ZWave hat Rudi und ein weiterer Kollege das mal getan. Meine Tests jedenfalls hatte ich mit Empfangsprobleme abgebrochen ;-)
Ich betreibe einen Cube mit SlowRF an CC0 und CC1 und HM an CC2 mit dem STACKABLE Modul ohne Probleme. Und auch bei majorshark sollte die Verwendung von STACKABLE und STACKABLE_CC keinen Unterschied machen, da bei ihm HM auf CC0 läuft und das immer gleich als CUL definiert wird.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 25 August 2018, 19:56:39
Na dann könnte er hetzt zurück und den Test machen, oder?

Wichtig ist, dass man beides nicht mixen darf und nach der umdefinition FHEM shutdown restartet!

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 25 August 2018, 20:51:17
Ich hatte für den MapleCUN den ich verkaufe auch mal eine Anleitung geschrieben um ihn schnell ein zu richten. Ich häng sie hier mal an falls da Interesse besteht.

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: majorshark am 26 August 2018, 09:04:56
So, ich habe den Maple jetzt auch in Kombi mit STACKABLE_CC auf meinem Testsystem eingerichtet und es läuft auch.  ??? Dann Scheint es ein Problem mit der Konfig auf meinem Livesystem zu geben. Das muss ich dann erst einmal Eruieren.

Was mich jetzt noch interessiert ist, welche Variante von den beiden ist den für welche Anwendung die Bessere? Oder anders was wird den Empfohlen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 26 August 2018, 16:53:11
Hi,

Module name # of FHEM installations # of definitions # of defined models
STACKABLE_CC 85 139 4
STACKABLE 22 44 -

Quelle:
https://fhem.de/stats/statistics.html
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Bootloader
Beitrag von: stefan-dd am 08 September 2018, 11:27:53
Hallo,

ich habe Probleme den richtigen Bootloader zu finden.
Gekauft habe ich den hier: https://www.aliexpress.com/snapshot/0.html?spm=a2g0s.9042647.0.0.674c4c4dNjjBhW&orderId=506428681246089&productId=32886367655
(https://www.aliexpress.com/snapshot/0.html?spm=a2g0s.9042647.0.0.674c4c4dNjjBhW&orderId=506428681246089&productId=32886367655)
Wenn ich diesen File flashe: maple_mini_boot20.bin stürzt er anscheinend ab. Die LED blinkt ganz kurz schnell, dann ca.3s langsamer und geht dann aus. Programmiere ich maple_mini_boot.bin blinkt die LED ebenfalls kurz schnell, dann dauerhaft langsamer.
Mit lsusb bekomme ich das Device so angezeigt: Bus 002 Device 059: ID 1eaf:0003 ... irgendwie unvollständig.
Unter Windows bekomme ich gar keine Programmierung hin.
Wenn ich MapleCUNx4_W5100_BL.bin aufspiele bleibt die LED dauerhaft aus.
Das programmieren des Bootloaders mache ich richtig, aber welches File ist richtig?
Was muss die LED machen wenn es richtig läuft?
Wie bekomme ich die  MapleCUNx4_W5100_BL.bin korrekt drauf?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 11 September 2018, 18:49:16
Wie das Flashen geht steht alles hier: https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 13 September 2018, 22:29:47
Ich muss heute mal ein großes Lob aussprechen an alle die an der Entwicklung des MapleCUN beteiligt waren/sind.

Ich habe heute die neueste Platine von Ranseyer mit den ersten Teilen zusammen gelötet, mit einem CC1101-868MHz und dem HM-UART Modul. Die Firmware aufgespielt und schon konnte ich auf Anhieb CC1101 und den HM-UART ohne Probleme in FHEM integrieren.

Macht weiter so Jungs und Mädels.  ;)




Das einzige was ich nicht verstehe ist, warum man den CUL und die anderen Schnittstellen über ttyACMx einbinden sollte, anstatt über /dev/serial/by-id/usb-STM32_MapleCUL_f173b922-if04@115200
Die Version über Serial-By-ID ist doch universeller und bleibt auch nach einem Restart und Umstecken des Maple an einen anderen USB-Port identisch.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 14 September 2018, 07:02:29
Hi,
Ja ich binde auch über by-id ein. Spricht nichts dagegen ;-)
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 14 September 2018, 07:17:01
Zitat von: RaspiLED am 14 September 2018, 07:02:29
Ja ich binde auch über by-id ein. Spricht nichts dagegen ;-)

Das es funktioniert, weiß ich ja. Ich wundere mich nur, warum man es überall mit ttyACMx findet.


Und weil es gerade so schön ist: LaCrosse funktioniert auch auf Anhieb mit dem 868MHz Modul.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 14 September 2018, 08:20:38
Moin,
Das ist eben der wichtige Unterschied zwischen CUL, nanoCUL und MapleCUL. Der Linuxtreiber legt mal ttyACMx mal ttyUSBx an, daher wird darauf hingewiesen. Das man besser by-id (oder zur Not by-path) macht lernt man dann ja und kann das immer selbst umsetzen ;-)
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 14 September 2018, 08:28:59
Moin zusammen,
Zitat von: RaspiLED am 14 September 2018, 08:20:38Das man besser by-auf (oder zur Not by-path) macht lernt man dann ja und kann das immer selbst umsetzen ;-)
Wie viele Fälle in der letzten Zeit hatten wir, in denen die Umstellung auf "by-.*" nur partiell erfolgt ist und es uU. vermutlich  auch deswegen noch zu Problemen kam? Würde mal 2-3 in den letzten 3 Monaten veranschlagen :( .
Zitat von: gloob am 14 September 2018, 07:17:01
Das es funktioniert, weiß ich ja. Ich wundere mich nur, warum man es überall mit ttyACMx findet.
Vermutlich, weil es die "schnelle Lösung" für die ist, die nur ein USB-Interface nutzen.
"by-id" ist da viel erklärungsbedürftiger und interessiert die meisten erst, wenn es zu Konflikten gekommen ist und "plötzlich" irgendwas nicht mehr funktioniert wie erwartet. Und da die meisten erst mal in Unkenntnis der Materie ihre Nanos in China kaufen (WCH-Chips), müßte man dann auch gleich noch "by-path" erklären...
Beim erstbesten Umzug des Servers auf andere Hardware ist "by-path" dann spätestens völlig in Vergessenheit geraten; auch nicht lustig ;) . Als Alternative gefakte FTDI's zu empfehlen, ist auch keine Lösung.

Vielleicht sollte man einen zentralen Artikel "Mehrere USB-Devices nutzen" im Wiki erstellen, das Thema wird ja immer wichtiger seit den Zeiten, in denen man eigentlich "nur einen CUL" benötigte.

Gut, dass es die MapleCUx gibt, da hat man gleich 4 (bzw. bis zu 6) derartige Probleme weniger :) . Auch von meiner Seite ein großes DANKE an die Macher!

Gruß, Beta-User
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 14 September 2018, 08:58:49
Naja, der Wiki Artikel ist ja zu 99% von mir schätze ich. (Ein Wiki darf jeder editieren!)
Ich habe ehrlich gesagt auch wenig Lust das by-* Thema zu beschreiben. Das gehört eher in nen zentralen Artikel, und auf den kann man verweisen.

(Beim Maple CUL finde ich ist die sinnvollste Einbindung per LAN. Daher ist der USB Part m.E. weniger wichtig.)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 14 September 2018, 09:21:08
Nochmal ein Moin, insbesondere @Ranseyer :) .

Mein Betrag war definitiv nicht als Kritik am bestehenden Artikel zum MapleCUx gedacht! Absulut richtig: Sowas sollte an zentraler Stelle stehen und ggf. dann von diesem Artikel dahin verlinkt werden (ähnlich wie das mit der Einbindung diverser serieller Geräte für den PI). Vielleicht findet sich ja ein Freiwilliger, es darf jeder... ;)

(Was in der jeweiligen Installation und nach Ansicht des "admin" sinnvoll ist, hängt wie meistens von dem Umständen des Einzelfalles ab... Ich bevorzuge an sich wo möglich USB, aber der MapleCUN ist auch per LAN angebunden - Hintergrund: Reichweitenvergrößerung...)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 14 September 2018, 10:10:22
Moin zusammen,

nach viel Unterstützung von Ranseyer habe ich es geschafft, eine neue a-culfw auf den MapleCUN zu flashen (mir war nicht klar, dass ich nach dem Einstecken nur innerhalb einer Sekunde flashen kann),
allerdings funktioniert bei mir das LAN nicht mehr.

Vorher war der MapleCUN mit fester IP per telnet im Einsatz, wenn ich nun LAN anschließe, blinkt zwar die LED, die die Datenübertragung anzeigt (sowohl am Switch als auch am Maple), allerdings sehe ich in der Fritzbox kein entsprechendes Gerät, unter der alten IP ist leider auch nichts erreichbar. Auch via nmap auf dem Nuc finde ich im gesamten /22er Netzwerk kein entsprechendes Gerät...

Würde es auch per USB versuchen, aber ich sehe das Gerät am NUC nicht unter /dev

root@server02:~/a-culfw/culfw/Devices/MapleCUN# tail -f /var/log/syslog
Sep 14 07:53:36 server02 kernel: [32320.087250] usb 1-2: new full-speed USB device number 10 using xhci_hcd
Sep 14 07:53:36 server02 kernel: [32320.236802] usb 1-2: New USB device found, idVendor=1eaf, idProduct=0003
Sep 14 07:53:36 server02 kernel: [32320.236809] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 14 07:53:36 server02 kernel: [32320.236814] usb 1-2: Product: Maple 003
Sep 14 07:53:36 server02 kernel: [32320.236819] usb 1-2: Manufacturer: LeafLabs
Sep 14 07:53:36 server02 kernel: [32320.236823] usb 1-2: SerialNumber: LLM 003


Habe zwischen Gigabit-Switch und Maple auch schon einen 100MBit-Switch gehängt, aber das zeigte keine Änderung...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 14 September 2018, 11:10:15
- Wenn du eine alte Firmware flasht kannst du auf der Debug Konsole Ausgaben sehen... (Also auch was schief läuft)


-Hast Du eine Firmware für den W5500 LAN Chip aufgespielt ?
-Ist die Firmware aktuell genug und für die Nutzung mit dem Bootloader vorgesehen ? (Welche genau?)

-Was sagt denn lsusb wenn du per USB anschliesst ? (nach dem Leaflabs Device = Bootloder) muss noch das MAPLE-CUL Device auftauchen, habe gerade nicht im Kopf wie das genau heißt)
Solange hier nichts kommt läuft die Firmware nicht...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 14 September 2018, 11:23:49
Zitat- Wenn du eine alte Firmware flasht kannst du auf der Debug Konsole Ausgaben sehen... (Also auch was schief läuft)
Was meinst du mit der debug-Konsole, also wo seh ich das? Beim Flashvorgang?

Zitat-Hast Du eine Firmware für den W5500 LAN Chip aufgespielt ?
Ja, war in dem von dir erstellten Script auch so voreingestellt

Zitat-Ist die Firmware aktuell genug und für die Nutzung mit dem Bootloader vorgesehen ? (Welche genau?)
Die Firmware war die aktuellste a-culfw (via git, dann kompiliert)

Zitat-Was sagt denn lsusb wenn du per USB anschliesst ? (nach dem Leaflabs Device = Bootloder) muss noch das MAPLE-CUL Device auftauchen, habe gerade nicht im Kopf wie das genau heißt)
Solange hier nichts kommt läuft die Firmware nicht...
Habe den Maple mal abgesteckt und wieder angesteckt und eine Weile gewartet...
root@server02:~# tail -f /var/log/syslog
Sep 14 11:20:54 server02 kernel: [  188.120270] usb 1-2: USB disconnect, device number 3
Sep 14 11:20:57 server02 kernel: [  191.263166] usb 1-2: new full-speed USB device number 4 using xhci_hcd
Sep 14 11:20:57 server02 kernel: [  191.391198] usb 1-2: device descriptor read/64, error -71
Sep 14 11:20:57 server02 kernel: [  191.648495] usb 1-2: New USB device found, idVendor=1eaf, idProduct=0003
Sep 14 11:20:57 server02 kernel: [  191.648504] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 14 11:20:57 server02 kernel: [  191.648509] usb 1-2: Product: Maple 003
Sep 14 11:20:57 server02 kernel: [  191.648514] usb 1-2: Manufacturer: LeafLabs
Sep 14 11:20:57 server02 kernel: [  191.648518] usb 1-2: SerialNumber: LLM 003

(Stand 11:23)

Die Ausgabe von lsusb ist:
root@server02:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0aa7 Intel Corp.
Bus 001 Device 004: ID 1eaf:0003
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Nachtrag:
Habe gerade versucht, die Firmware (MapleCUNx4_W5500_BL.bin) neu zu flashen:

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [=========================] 100%        66544 bytes
Download done.
Sent a total of 66544 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
root@server02:~/a-culfw/culfw/Devices/MapleCUN#

Ging ungewöhnlich schnell, der NUC steht in einem andren Raum.
Ich habe das Script gestartet, bin rübergehetzt, habe den Maple angesteckt, als ich zurück war, war das Ding fertig geflasht (<5 Sekunden schätze ich), ist das normal?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 14 September 2018, 11:28:43
Das bedeutet wohl die Firmware läuft nicht.

Bei W5100 Firmware würde der MAPLE-CUL per USB erkannt, aber das W5500 LAN Modul würde nicht funktionieren.

Vermutung:
-Somit ist es eine Firmware zum Flashen ohne Bootloader (mir immer noch unklar welche du ganz genau hast), die würde gar nicht laufen
-oder falscher Bootloader der die Firmware nicht startet

ZitatWas meinst du mit der debug-Konsole, also wo seh ich das?
Die 4 Pins an denen Debug steht, über die du auch den Bootloader getauscht hast, dort mit 115200 Baud lauschen (z.B. per Arduino IDE, Terminial-Prog, ...)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 14 September 2018, 11:38:21
Zitat-Somit ist es eine Firmware zum Flashen ohne Bootloader (mir immer noch unklar welche du ganz genau hast), die würde gar nicht laufennano
Die Firmware habe ich so bezogen:
git clone https://github.com/heliflieger/a-culfw.git
und dann kompiliert. Habe da nichts umbenannt oder so, die Datei hieß auch nach dem Kompilieren wie die Datei in deinem Script.

Der Bootloader stammt aus einem Forenpost zum MapleCUL (aus dem Anhang, https://forum.fhem.de/index.php?topic=80872.0 ), aber Dateigröße und Dateiname ist identisch mit dieser hier aus der Flashanleitung:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/binaries/maple_mini_boot20.bin
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 14 September 2018, 11:40:11
OK, dann starte doch erst mal damit: https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw

Wenn das läuft ist der Bootloader OK.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 14 September 2018, 12:03:11
ZitatOK, dann starte doch erst mal damit: https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw
Damit läuft's, also hat meine verwendete Firmware wohl eine Macke.

Kannst du mir sagen, welche ich dann zum Kompilieren nehmen muss?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 14 September 2018, 12:08:57
Du kannst bestimmt die genannte Kompilieren musst dich aber mit den Optionen befassen.

Ich habe nur ganz anfangs kopiliert und nehme nun nur noch fertige. (Jetzt hätte ich wieder nen Grund: Debug Port wieder aktivieren so wie früher anstatt diesen als UART für die Anbindung per ESP usw. vorzusehen)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 14 September 2018, 12:37:17
Okay, da komme ich wohl wieder an meine Grenzen...
Weiß da jemand, was ich beim Kompilieren beachten muss bzw. welche Optionen geändert werden müssen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 14 September 2018, 12:40:47
Schau doch mal das Makefile und Boards.h an: https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/MapleCUN

Evtl. klärt sich da manches... (Vor allem mal die Targets im Makefile anschauen)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 14 September 2018, 12:58:10
Ich bin da Laie, was mir nur auffällt ist, dass bei den H_SUBDIRS der Odner für den W5500 fehlt, der W5100 ist drin.
Das wars aber leider nicht.

Drin steht auch "BOOTLOADER=TRUE", aber ich weiß nun nicht, ob das bedeutet, dass man von einem vorhandenen Bootloader ausgeht oder dass einer mitgeliefert werden soll.

Möchte halt nicht zu sehr ins Blaue probieren, sonst schieße ich noch was...

Während des Kompilierens gab's diese Ausgaben/Warnungen, ich weiß jetzt nicht, ob die was damit zu tun haben, oder ob das "normal" ist...
root@server02:~/a-culfw/culfw/Devices/MapleCUN# make > make.log
../../clib/fband.c: In function 'readEEpromValue':
../../clib/fband.c:24:11: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   d = erb((uint8_t *)addr);
           ^
../../clib/fncollection.c: In function 'read_eeprom':
../../clib/fncollection.c:154:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     d = erb((uint8_t *)addr);
             ^
../../clib/fncollection.c: In function 'write_eeprom':
../../clib/fncollection.c:218:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     ewb((uint8_t*)addr, hb[d-1]);
         ^
../../clib/fncollection.c:228:11: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
       ewb((uint8_t*)++addr, hb[0]);
           ^
../../clib/fncollection.c: In function 'prepare_boot':
../../clib/fncollection.c:350:5: warning: this 'while' clause does not guard... [-Wmisleading-indentation]
     while(1);
     ^~~~~
../../clib/fncollection.c:369:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'while'
  USBD_Disconnect();
  ^~~~~~~~~~~~~~~
../../clib/rf_send.c: In function 'sendraw':
../../clib/rf_send.c:104:16: warning: unused variable 'sum' [-Wunused-variable]
   int8_t i, j, sum = (nbyte+2)*repeat + addH + addL;
                ^~~
../../Wiznet/Ethernet/wizchip_conf.c:166:7: warning: missing braces around initializer [-Wmissing-braces]
       {
       ^
../../Wiznet/Ethernet/wizchip_conf.c:166:7: note: (near initialization for 'WIZCHIP')
../../Wiznet/Internet/DHCP/dhcp.c: In function 'parseDHCPMSG':
../../Wiznet/Internet/DHCP/dhcp.c:587:4: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
    else return 0;
    ^~~~
../../Wiznet/Internet/DHCP/dhcp.c:588:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'else'
  if (svr_port == DHCP_SERVER_PORT) {
  ^~
root@server02:~/a-culfw/culfw/Devices/MapleCUN#
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 17 September 2018, 20:05:45
Edit: Ein paar mal raw e hat geholfen um den MapleCUN wieder auf den richtigen Weg zu setzen.




Hat jemand eine Idee, warum mein MapleCUN nach eine Neustart von FHEM keine LaCrosse Geräte mehr empfängt?

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_f173b922-if00@38400 1432
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_f173b922-if00@38400
   FD         106
   FHTID      1432
   MAPLE_CUL868_MSGCNT 1
   MAPLE_CUL868_TIME 2018-09-17 20:04:34
   NAME       MAPLE_CUL868
   NR         815
   PARTIAL   
   RAWMSG     01
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) MapleCUNx4_01 (F-Band: 868MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-09-17 19:59:09   ccconf          freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB
     2018-09-17 20:04:02   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
     2018-09-17 20:04:34   state           Initialized
     2018-09-17 19:57:15   uptime          0 00:07:06
     2018-09-17 19:57:08   version         V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) MapleCUNx4_01 (F-Band: 868MHz)
Attributes:
   connectCommand Nr1
   rfmode     SlowRF
   room       MapleCUN
   verbose    5


Bis vor dem Neustart ging es noch wunderbar.

Folgendes steht im Log:

2018.09.17 20:04:34 5: SW: Nr1
2018.09.17 20:04:34 5: CUL/RAW: /01

2018.09.17 20:04:34 4: CUL_Parse: MAPLE_CUL868 01
2018.09.17 20:04:34 5: MAPLE_CUL868: dispatch 01
2018.09.17 20:04:34 3: MAPLE_CUL868: Unknown code 01, help me!


Starte ich neu oder reinitialisiere ich den CUL mit Nr1 neu kommen manchmal Nachrichten an. Aber maximal 2-3 Stück.

Das Homematic Modul was mit dran hängt, überträgt fleißig seine Daten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 18 September 2018, 19:41:43
Hat jemand vielleicht bitte einen Tipp wie man esp-link einstellen muss für den MapleCUN?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 18 September 2018, 20:26:52
Hi,
Wie meinst Du das? ESPLink gibt Dir dann die serielle Debug Ausgabe des Maple über WLAN. Wie es einzustellen ist hängt Dich an Deinem ESP Chip (-01, -12F, ... oder Wemos) und welche Verkabelung du machst.
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 19 September 2018, 00:17:14
Ich konnte mein Problem mit der Firmware nch unzähligen Stunden des rumprobierens einfach lösen, zumindest indirekt.
Die auf meinem NUC (Ubuntu 18.04) kompilierte Firmware habe ich absolut nicht zum Laufen bekommen, bin aber dann mal auf die Idee gekommen, die Firmware auf einem andren Linux-System zu kompilieren,
da musste dann der Debian-Rootserver ran.
Diese Firmware funktioniert auf Anhieb... weiß Gott warum... Hauptsache es geht nun!  8)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 19 September 2018, 07:54:56
Zitat von: RaspiLED am 18 September 2018, 20:26:52
Hi,
Wie meinst Du das? ESPLink gibt Dir dann die serielle Debug Ausgabe des Maple über WLAN. Wie es einzustellen ist hängt Dich an Deinem ESP Chip (-01, -12F, ... oder Wemos) und welche Verkabelung du machst.
Gruß Arnd

Sorry. Ich nutze die MapleCUN Large Platine von Ranseyer. Aber im Moment scheint der ESP-01 eh nicht richtig zu laufen. Muss ich wohl doch mal ein paar Stützkondensatoren verlöten. Danach geht es nochmal an die Parameter von esp-link aber ich glaube ich habe es mitlerweile verstanden :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 19 September 2018, 19:52:38
Hallo,

wie geschrieben, ist mein MapleCUN geflasht und funktioniert, aber:
Mehrmals am Tag verschwindet er und taucht kurz darauf wieder auf,
sieht dann über den Tag hinweg so aus:

2018.09.19 02:10:43 1: Error in CUL_MAX_SendQueueHandler: CUL mCUN4 did not answer request for current credits. Waiting 5 seconds.
2018.09.19 02:10:43 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 02:10:43 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 02:10:43 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 02:10:43 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 02:10:43 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 02:11:09 2: CUL_MAX_SendQueueHandler: Missing ack from 19c00a for 0f01040312345619c00a001213028b46
2018.09.19 04:12:38 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 04:12:38 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 04:12:38 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 04:12:38 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 04:12:38 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 04:12:38 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 06:14:17 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 06:14:17 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 06:14:17 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 06:14:17 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 06:14:17 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 06:14:17 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 08:10:43 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 08:10:43 1: Error in CUL_MAX_SendQueueHandler: CUL mCUN4 did not answer request for current credits. Waiting 5 seconds.
2018.09.19 08:10:43 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 08:10:43 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 08:10:43 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 08:10:43 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 08:10:44 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 08:11:09 2: CUL_MAX_SendQueueHandler: Missing ack from 19c00a for 0f02040312345619c00a001213088b46
2018.09.19 10:11:51 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 10:11:51 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 10:11:51 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 10:11:51 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 10:11:51 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 10:11:51 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 12:13:14 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 12:13:14 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 12:13:14 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 12:13:14 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 12:13:14 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 12:13:14 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 14:10:43 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 14:10:43 1: Error in CUL_MAX_SendQueueHandler: CUL mCUN4 did not answer request for current credits. Waiting 5 seconds.
2018.09.19 14:10:43 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 14:10:43 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 14:10:43 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 14:10:43 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 14:10:44 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 14:10:51 1: Error in CUL_MAX_SendQueueHandler: CUL mCUN4 did not answer request for current credits. Waiting 5 seconds.
2018.09.19 14:10:53 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 14:10:53 1: Error in CUL_MAX_SendQueueHandler: CUL mCUN4 did not answer request for current credits. Waiting 5 seconds.
2018.09.19 14:10:53 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 14:10:53 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 14:10:53 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 14:10:54 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 14:10:54 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 14:11:19 2: CUL_MAX_SendQueueHandler: Missing ack from 19c00a for 0f03040312345619c00a0012130e8b50
2018.09.19 16:12:48 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 16:12:49 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 16:12:49 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 16:12:49 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 16:12:49 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 16:12:49 3: mCUN4: Possible commands: CAZNELYVXfz
2018.09.19 18:13:40 1: 192.168.22.91:2323 disconnected, waiting to reappear (mCUN1)
2018.09.19 18:13:41 3: mCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.09.19 18:13:41 1: 192.168.22.91:2323 reappeared (mCUN1)
2018.09.19 18:13:41 3: mCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 18:13:41 3: mCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.09.19 18:13:41 3: mCUN4: Possible commands: CAZNELYVXfz


Woran liegt das?

Kann ich da 'was dran ändern?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 21 September 2018, 01:10:54
Meine Probleme gehen weiter, verdammt  ;D

Klappt alles soweit, nur der letzte Chip auf dem MapleCUN (Ant1, mCUN2) , der auf 433 Mhz funken soll (vermute ich mal), der reagiert weder auf Smartwares-Wandschalter (erst wollte ich die schon in die Tonne kloppen) noch auf die Intertechno-Fernbedienung...
CCconf gibt 868 Mhz aus, reichts, die Frequenz (freq) dann einfach auf 433Mhz zu setzen?

Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfxz*
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        mCUN1
   IODev      mCUN1
   NAME       mCUN2
   NOTIFYDEV  mCUN1
   NR         28
   NTFY_ORDER 50-mCUN2
   PARTIAL   
   RAWMSG     *S5657A8011E00093C4B0001000000001C40
   STACKED    mCUN3
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.26.03 a-culfw Build: private build (unknown) MapleCUNx4_8F (F-Band: 433MHz)
   initString X21
Ar
   mCUN2_MSGCNT 2625
   mCUN2_TIME 2018-09-21 13:30:12
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-09-21 01:09:56   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-09-21 01:09:48   cmds             b C F i A Z N E G M K L U Y R T V W X f x z *
     2018-09-19 23:13:15   credit10ms      3038
     2018-09-19 23:13:18   fhtbuf          AE
     2018-09-19 23:13:21   raw             ? ( is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f x z *
     2018-09-21 13:30:12   state           Initialized
     2018-09-19 23:13:34   uptime          No answer
     2018-09-19 23:17:00   version         V 1.26.03 a-culfw Build: private build (unknown) MapleCUNx4_8F (F-Band: 433MHz)
Attributes:
   group      Schnittstellen
   room       System
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 21 September 2018, 12:23:26
Hi,
Bilder! Bitte durch ein
list mCUN2
ersetzen.

Wenn Du sagst der soll 433 MHz sein, dann
set mCUN2 frequency 433.920

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 21 September 2018, 13:39:50
ZitatHi,
Bilder! Bitte durch ein
Code: [Auswählen]

list mCUN2

ersetzen.
erledigt

Zitatset mCUN2 frequency 433.920

Habe ich gemacht, wird aber nirgends angezeigt, ist das normal?
Steht nur in der Log:
2018.09.21 13:38:16 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz

Was mich stutzig macht:
get ccconf gibt Folgendes aus:
mCUN2 ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: LuckyDay am 21 September 2018, 20:05:15
initString X21
Ar


heißt , dass er im HM-Mode läuft, und da ist die
ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
fest und nicht änderbar.

Ich habe aber  keine Ahnung von (MapleCUN) :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 21 September 2018, 20:10:13
Danke, das bringt mich schonmal weiter, zumindest beim Eingrenzen des Fehlers!

rfMode HomeMatic hat eigentlich nur der mCUN1

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.22.91:2323 1339
   DeviceName 192.168.22.91:2323
   FD         10
   FHTID      1339
   NAME       mCUN1
   NR         26
   PARTIAL   
   RAWMSG     **SF457A8011E00093D7E0002000000001C44
   STACKED    mCUN2
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.03 a-culfw Build: private build (unknown) MapleCUNx4_8F (F-Band: 868MHz)
   initString X21
Ar
   mCUN1_MSGCNT 1364
   mCUN1_TIME 2018-09-21 20:09:12
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-09-21 01:08:51   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-09-21 13:49:15   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2018-09-21 20:09:12   state           Initialized
Attributes:
   group      Schnittstellen
   rfmode     HomeMatic
   room       System


Ich habe den rfMode des mCUN1 testweise auf MAX gestellt,
dann steht beim mCUN2
initString X21 Zr

Nehme ich beim mCUN1 den rFmode raus, erhalte ich:
initString X21 und get ccconf zeigt mir die 433 Mhz an...

Also irgendwas stimmt da nicht :-/
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: szoller am 23 September 2018, 15:47:02
Kanns sein, dass da irgendwie die Zuordnung zu den Transceivern nicht klappt?
Bei autocreate wird nämlich immer auch der nächsthöhere Transceiver des MapleCUN gewählt als der, der eigentlich den entspr. rfMode eingestellt bzw. die entspr. Frequenz hat...?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 23 September 2018, 21:19:48
Hat jemand einen Tipp, warum mein MapleCUN im Homematic Modus immer nur 1-2 Nachrichten empfängt und dann nichts mehr aktualisiert. Das HM-MOD-UART Modul auf der Platine funktioniert ohne Probleme.
Hier ist ein Auszug aus dem Log. Es kommt also scheinbar etwas an:

2018.09.23 21:16:36 4: CUL_Parse: MAPLE_CUN2 A 14 00 0010 444007 000000 004648454D34343430303735 -47.5
2018.09.23 21:16:36 5: MAPLE_CUN2: dispatch A14000010444007000000004648454D343434303037::-47.5:MAPLE_CUN2
2018.09.23 21:16:47 4: CUL_Parse: MAPLE_CUN2 A 14 00 0010 444007 000000 004648454D34343430303735 -47.5
2018.09.23 21:16:47 5: MAPLE_CUN2: dispatch A14000010444007000000004648454D343434303037::-47.5:MAPLE_CUN2
2018.09.23 21:16:59 4: CUL_Parse: MAPLE_CUN2 A 14 00 0010 444007 000000 004648454D34343430303735 -47.5
2018.09.23 21:16:59 5: MAPLE_CUN2: dispatch A14000010444007000000004648454D343434303037::-47.5:MAPLE_CUN2
2018.09.23 21:17:00 4: CUL_Parse: MAPLE_CUN2 A 13 12 0083 4A77E9 F00001 0004C601D01489C3B1BB28 -54
2018.09.23 21:17:00 5: MAPLE_CUN2: dispatch A131200834A77E9F000010004C601D01489C3B1BB::-54:MAPLE_CUN2
2018.09.23 21:17:10 4: CUL_Parse: MAPLE_CUN2 A 14 00 0010 444007 000000 004648454D34343430303735 -47.5
2018.09.23 21:17:11 5: MAPLE_CUN2: dispatch A14000010444007000000004648454D343434303037::-47.5:MAPLE_CUN2
2018.09.23 21:17:22 4: CUL_Parse: MAPLE_CUN2 A 14 00 0010 444007 000000 004648454D34343430303735 -47.5
2018.09.23 21:17:22 5: MAPLE_CUN2: dispatch A14000010444007000000004648454D343434303037::-47.5:MAPLE_CUN2
2018.09.23 21:17:34 4: CUL_Parse: MAPLE_CUN2 A 14 00 0010 444007 000000 004648454D34343430303735 -47.5
2018.09.23 21:17:34 5: MAPLE_CUN2: dispatch A14000010444007000000004648454D343434303037::-47.5:MAPLE_CUN2
2018.09.23 21:17:34 1: Attribute valuesformat mismatch at HM_444001_Values - expected 4 items but got 3 items
2018.09.23 21:17:43 4: CUL_Parse: MAPLE_CUN2 A 06 91 87CC B5453F 2B  -52.5
2018.09.23 21:17:43 5: MAPLE_CUN2: dispatch A069187CCB5453F
2018.09.23 21:17:43 3: MAPLE_CUN2: Unknown code A069187CCB5453F, help me!
2018.09.23 21:17:45 4: CUL_Parse: MAPLE_CUN2 A 14 00 0010 444007 000000 004648454D34343430303735 -47.5
2018.09.23 21:17:45 5: MAPLE_CUN2: dispatch A14000010444007000000004648454D343434303037::-47.5:MAPLE_CUN2


Und natürlich noch ein List vom Device.

Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfxz
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        MAPLE_CUN1
   IODev      MAPLE_CUN1
   MAPLE_CUN2_MSGCNT 260
   MAPLE_CUN2_TIME 2018-09-23 21:26:02
   NAME       MAPLE_CUN2
   NOTIFYDEV  MAPLE_CUN1
   NR         845
   NTFY_ORDER 50-MAPLE_CUN2
   PARTIAL   
   RAWMSG     A14000010444007000000004648454D34343430303735
   RSSI       -47.5
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) MapleCUNx4_03 (F-Band: 868MHz)
   initString X21
Ar
   owner_CCU  vccu
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-09-23 21:10:47   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-09-23 21:10:20   cmds             b C F i A Z N E G M K L U Y R T V W X f x z
     2018-09-23 21:26:02   state           Initialized
Attributes:
   hmId       49AD48
   rfmode     HomeMatic
   room       MapleCUN
   verbose    5
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: HannesDi am 09 Oktober 2018, 23:55:25
Hi,

auf die gefahr hin, dass ich mit meinem ersten beitrag gleich mal ne richtig blöde frage stelle....

ich hab vor mir so ein teil zu bauen aber eine frage wirft sich mir jetzt gerade auf...

die platinen revisionen.. aktuell ist wohl die V3.3 - https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/Archiv/V3.3 (https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/Archiv/V3.3) ?
kann man die verwenden oder sollte man die nicht verwenden und statt dessen die v2.1 nutzen?

hintergrund der frage ist: eistee nutzt die v2.1 für ihr angebot, gibts da einen guten grund für oder etwas dass gegen die v3.3 spricht?

also ausser den 8 airwires die vermutlich völlig unerheblich sind für die platine...

grüße
Hannes
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 10 Oktober 2018, 08:35:13
Die Frage ist Gut, passt nur nicht in den Thread von Telekatz. Denn es geht dir ja um die mechanische Umsetzung.

Trotzdem die Antwort. Du kannst alle Versionen verwenden. Die V2 hat noch viel mehr unnötigen Mist integriert welcher das Leben schwerer macht. Ab V3 geht das über AddOn was viel geschmeider zum aufbauen und vor allem auch debuggen ist. Außerdem ist mit den AddOns viel mehr möglich als mit einer starren Platine.

PS: Falls du rasch eine aktuelle V3 Platine willst: PN an mich... (Hier war mal der Thread, der müsst nur mal etwas aktualisiert werden... https://forum.fhem.de/index.php/topic,80319.0.html)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: HannesDi am 11 Oktober 2018, 23:49:02
Zitat von: Ranseyer am 10 Oktober 2018, 08:35:13
Die V2 hat noch viel mehr unnötigen Mist integriert welcher das Leben schwerer macht. Ab V3 geht das über AddOn was viel geschmeider zum aufbauen und vor allem auch debuggen ist. Außerdem ist mit den AddOns viel mehr möglich als mit einer starren Platine.

PS: Falls du rasch eine aktuelle V3 Platine willst: PN an mich... (Hier war mal der Thread, der müsst nur mal etwas aktualisiert werden... https://forum.fhem.de/index.php/topic,80319.0.html)

Alles klar, danke für die rasche antwort und das angebot zur v3 platine, ich hab das ganze aber jetzt in einer grossbestellung verarbeitet, hab es ja nicht eilig und die anderen teile müssen ja auch erst noch ankommen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 23 Oktober 2018, 09:13:51
Hi,

ich wollte mal fragen ob es möglich währe die MapleCUN Firmware so zu erweitern das die 4 Funkmodule nicht nur über Stackable auf einem TCP Port erreichbar sind sondern Modul 2-4 jeweils auch noch einen zusätzlichen eigenen TCP Port bekommen.

Hintergrund ist der, das es Stackable nur für FHEM gibt und man mit extra Ports z.B. im iobroker auch alle 4 Module verwenden könnte.

Grüße Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 23 Oktober 2018, 17:58:10
Sofern ein W5500 verbaut ist sollte es schon möglich sein. Aber das fehlt mir jetzt irgendwie die Motivation, das zu machen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 26 Oktober 2018, 20:15:41
Hallo Zusammen,

gibt es irgendeinen Trick unter Windows 10 mit dem"STM32 Flash loader Demonstrator" den Bootloader zu flashen mit einem FTDI Adapter ?
Bin nach https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md) vorgegangen.

Habe den Marplemini über USB an ein Netzteil das 5V liefert angeschlossen. FTDI an RX und TX (auch mal getauscht)
Nach einer Treiberänderung mit Zadiag habe ich es auch schon versucht, aber dann kommt komischerweise immer  das der Com port belegt wäre.

wäre klasse wenn mi jemand auf die Sprünge helfen könnte....

Gruß

Markus


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 27 Oktober 2018, 10:44:30
Hallo Markus,

ich würde vorschlagen die Fehlerquellen nacheinander zu diagnostizieren.

Als ersten Schritt würde ich den Seriell-Adapter + die COM-Schnittstelle im System überprüfen:
hier (http://helmpcb.com/software/serial-port-monitor) gibt es ein hilfreiches Tool zum Anzeigen der Seriellen in der Taskleiste  unter Windows und  hier (https://sourceforge.net/projects/y-a-terminal/) ein Beispiel-Terminalprogramm.

Im nächsten Schritt sollte bei korrekter Verdrahtung und Vorgehensweise (https://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/) auch das Flashen funktionieren ...

Die Zadig-Treiberänderung war, meiner Meinung nach, für diesen Zweck sinnlos und ggf. kontraproduktiv ....

Grüße,
Jürgen


PS: Noch ein Hinweis:
Es gibt aber Nachbauchips, die FTDI lahm gelegt hat ... (https://www.windows-net.de/33942.windows-update-ftdi-ports-und-ftdi-usb).
Hier im Thread nach dem richtigen Bootloader-Binary für Deinen MapleCUL-Typ suchen (oder STM32duino-bootloader-binaries (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/binaries))
http://wiki.stm32duino.com/index.php?title=Uploading_a_sketch (http://wiki.stm32duino.com/index.php?title=Uploading_a_sketch)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 27 Oktober 2018, 13:24:39
Hallo Jürgen,

also den Bootloader habe in nun drauf :-)
Hab die devices, auch hidden mal deinsiatlliert und neu installiert. Danach ging es dann. Aber mit Brücke Boot1 auf GND.

Die eigentliche FW kann man doch nun über USB flashen oder?

Aber da bekomme ich folgende Meldung.


Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Cannot open DFU device 1eaf:0003
No DFU capable USB device available


Oder muss die auch über FTDI mir Brücke boot GND geflasht werden?

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Oktober 2018, 13:55:15
DFU geht nur ca. eine Sekunde lang nach dem einstecken, könnte das der Grund bei dir sein ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 27 Oktober 2018, 14:01:30
denke nicht, muss was anderes sein.

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Oktober 2018, 14:07:43
ZitatCannot open DFU device 1eaf:0003
Das sagt jedenfalls eindeutig dass zu dem Zeitpunkt keinb Bootloader mehr ansprechbar ist.

Am besten "tail -f /var/log/syslog" auf einer Linux-Kiste machen und anschliessend den Maple anschliessen, da muss zuerst das LeafLabs Device erscheinen nur nach kurzem Durchschnaufen macht das Gerät einen USB Disconnect und es wird versucht die Firmware zu starten. 
=> Also wenn alles läuft zwei Geräte hintereinander, bei dir muss zumindest der Bootloader zu sehen sein. Wenn nicht ist damit etwas faul.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 27 Oktober 2018, 14:11:24
mmmh... irgendwie seltsam.. jetzt hat es doch funktioniert. War wohl ein Timing Problem meiner Finger.. ;D


Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [=========================] 100%        66288 bytes
Download done.
Sent a total of 66288 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!



Erstmal danke für die Hilfe... werden bestimmt noch mehr Fragen diesbezüglich kommen.. :-)

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Oktober 2018, 14:17:33
Ich finde das kann man nur mit einem Mini-Sript welches in einer Schleife läuft zuverlässig machen. Das hab ich auch schon 1-2 Mal gepostet. (Und möglichweise auch in einer der beiden Wiki Seiten zum Thema)

Aber das ist nun ja gut, dass es geht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 27 Oktober 2018, 16:18:04
Hey,
da steht 100% ist das neu? Ich dachte es geht nicht komplett und funktioniert dann doch!?

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 28 Oktober 2018, 13:58:51
Hallo Zusammen,

wie bekommt man denn auf dem Debug port eine sinnvolle Ausgabe hin?
Der CUN ist noch nicht in FHEM definiert im Moment. Ich habe einen FTDI Adapter (5V) an DBG angeschlossen RX-RX TX-TX VCC-+ und GND-GND. Maplemini blinkt langsam vor sich hin aber in der Konsole bekomme nicht angezeigt.

Jemand eine Idee? :-(

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 28 Oktober 2018, 14:56:08
Zitat von: Telekatz am 18 Juni 2018, 09:34:48
Die Debugausgabe am Debug UART ist mit der Version 1.26.02 weggefallen.

Mit der Suchfunktion in fhem gefunden  ;)  :'(

Für was benötigst Du die Ausgabe? Hast Du Hoffnung, den Output deuten zu können, ohne Dich in den Sourcecode einzuarbeiten?

Verbose 5 auf dem Device ?

War die Konfiguration in fhem erfolgreich?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Oktober 2018, 16:40:48
Zitat von: Markus. am 28 Oktober 2018, 13:58:51
Jemand eine Idee? :-(


Immer noch ein:
tail -f /var/log/syslog und das Teil einstecken.

Dann: https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 28 Oktober 2018, 18:07:01
Zitat von: juergs am 28 Oktober 2018, 14:56:08
Mit der Suchfunktion in fhem gefunden  ;)  :'(

Für was benötigst Du die Ausgabe? Hast Du Hoffnung, den Output deuten zu können, ohne Dich in den Sourcecode einzuarbeiten?

Verbose 5 auf dem Device ?

War die Konfiguration in fhem erfolgreich?

Mist ja stimmt ja auch..Ist mir irgenwie untergegangen das das ab dem release 1.26.02 nicht mehr drin ist. Habs die Tage auch gelesen .. :-[
Werde es mal in Fhem definieren und dann weiter "spielen"..
Dachte nur man könnte auch in der Konsole sehen ob die Radios initialisiert werden ohne das der CUN an einem FHEM Server hängt.
Zitat von: Ranseyer am 28 Oktober 2018, 16:40:48

Immer noch ein:
tail -f /var/log/syslog und das Teil einstecken.

Dann: https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres
Werde das dann mal testen :-)

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Oktober 2018, 18:08:24
ZitatDachte nur man könnte auch in der Konsole sehen ob die Radios initialisiert werden ohne das der CUN an einem FHEM Server hängt.

Kann man. Muster ist im Wiki.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 28 Oktober 2018, 18:32:56
Zitat von: Ranseyer am 28 Oktober 2018, 18:08:24
Kann man. Muster ist im Wiki.

Ja aber über syslog und nicht auf einer Konsole verbunden mit dbg.. oder sehe ich im Moment den Wald vor lauter Bäumen nicht ?!?!?!  ;D ;D ;D

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 28 Oktober 2018, 18:50:32
Bei korrekter Definition und Funktion reicht eigentlich ein ccconf auf die Devices in fhem.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 28 Oktober 2018, 19:05:33
okay Danke Euch !!!! :-)

Gruß

Markus

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Oktober 2018, 19:11:07
Zitat von: Markus. am 28 Oktober 2018, 18:32:56
oder sehe ich im Moment den Wald vor lauter Bäumen nicht ?!?!?!  ;D ;D ;D

richtig...


-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar 18 2017 15:46:32 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x18
-I- Detected CC2: PN 0x00  VER 0x14
-I- Detected CC3: PN 0x00  VER 0x14
-I- Detected ethernet
-I- init USB
-I- init Complete
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 28 Oktober 2018, 19:15:55
gut also das..oder so ähnlich sollte man dann im syslog sehen..?


-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar 18 2017 15:46:32 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00  VER 0x14
-I- Detected CC1: PN 0x00  VER 0x18
-I- Detected CC2: PN 0x00  VER 0x14
-I- Detected CC3: PN 0x00  VER 0x14
-I- Detected ethernet
-I- init USB
-I- init Complete


Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Oktober 2018, 19:28:36
Ähh. nee !

Im Syslog steht weiterhin:

1. Leaflabs Device erkannt
1b USB Disconnect
2. MAPLE-CUL erkannt

Das gepostete steht im Wiki doch klar beschrieben:
ZitatBeispiel für Meldungen am Debug-Port mit 4 Transceivern und LAN-Modul:
Also die Ausgabe über dein FTDI (oder so) Teil wenn die Firmware etwas älter ist...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 28 Oktober 2018, 19:36:20
ja ... bis Firmware 1.26.02 ?!?! 8)

Ab dann wurde es doch rausgeholt. Ich habe 1.26.04 drauf.... ;-)

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Oktober 2018, 19:44:30
Dann ändere halt die Firmware, oder verzichte auf die Debug Ausgabe.

Syslog geht immer wenn per USB angeschlossen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 02 November 2018, 21:03:05
Hallo Zusammen,

Wie muss denn das Pin-Assignment ausshen beimder Verwendung eines ESP01 und Esp-Link?
Habe im Moment folgendes Problem. Und zwar habe ich nach folgender Anweisung einen ESP01 geflasht. https://www.iot-experiments.com/flashing-esp8266-esp01/ (https://www.iot-experiments.com/flashing-esp8266-esp01/)
Funktioniert auch soweit auf dem Breadboard. Kann ihn in mein Wlan einbinden und habe für das Pin-Assignment ESP01 pres-Setting ausgewählt. Hole ich aber nun den Esp vom Breadboard runter und steck ihn auf den Maple, startet er nicht mehr. :-(  Steck ich ihn wieder in das Breadboard funktioniert er einwandfrei. Kann das eventuell an einer falschen Pin-Zuordnung liegen oder muss auf dem Maple large noch was gemacht werden?

Gruß Markus
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 02 November 2018, 21:39:43
Hi,
Ist der vielleicht im Flash Mode auf der Maple Platine? Messe doch mal GPIO0 und CH_Pd nach.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 02 November 2018, 21:52:11
Da fehlt eine Brücke

(https://uploads.tapatalk-cdn.com/20181102/a7849e5c95b11d5426b471e618ca38f8.jpg)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 02 November 2018, 22:00:23
Ahh klasse danke dir, das werd ich morgen testen. Aber das pin-assignment kann man auf preset EsP01 lassen oder muss da was geändert werden?

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 03 November 2018, 07:14:54
Zitat von: gloob am 02 November 2018, 21:52:11
Da fehlt eine Brücke

(https://uploads.tapatalk-cdn.com/20181102/a7849e5c95b11d5426b471e618ca38f8.jpg)

Funktioniert nun nachdem ich die Brücke rein gemacht habe :-)
Danke Dir !!

Wie sieht es denn mit dem Pin-Assignment aus. Wid das einfach nur auf Preset ESP01 gestellt?

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 03 November 2018, 07:25:45
also habe jetzt mal die Settings wie im Bild, damit geht's :-)

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 03 November 2018, 13:41:10
UART pins: normal
RX pull-up: ja
Der Rest kann auf disable.

So liefere ich meine MapleCUN aus.

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Devender am 04 November 2018, 12:36:05
Hallo zusammen,

Ich bin vor einigen Tagen mit meinem Produktiven System von Whezzy auf Jessie geschwenkt und habe alles neu aufgesetzt. Mein altes System hatte eh einige Macken und der Schritt stand seit längerem an.

Der definierte Maple funktioniert eigentlich gut. Allerdings habe ich ein Problem, welches nur auftritt, wenn ich z.b Morgens per Zeitsteuerung meine Rollläden öffnen lasse.
Das funktioniert in zwei Steps. (DOIF) Zu erst, 10% und nach 10 min komplett hoch.
Dabei passiert es, dass bei 10% sich nicht alle Rollos bewegen oder sogar komplett hochfahren. Danach ist ein generelles Schalten über den Maple nicht mehr möglich.
Erst ein reboot vom System behebt das Problem und es läuft wieder alles. Auch kann ich dann die Rollläden alle mit einem Befehl hochfahren.

Ich hatte extra mal das Log auf 5 gestellt:

Code: [Auswählen]

2018.11.04 09:00:17 4: CUL_Parse: CUL868 * Ys A0 230A 707100 00
2018.11.04 09:00:17 5: CUL868: dispatch *YsA0230A70710000
2018.11.04 09:00:17 5: CUL868 sending *YsA9401229000081
2018.11.04 09:00:17 5: SW: *YsA9401229000081
2018.11.04 09:00:17 5: CUL/RAW: /*YsA2150C32100000

2018.11.04 09:00:17 4: CUL_Parse: CUL868 * Ys A2 150C 321000 00
2018.11.04 09:00:17 5: CUL868: dispatch *YsA2150C32100000
2018.11.04 09:00:18 5: CUL868 sending *YsAA11071A000097
2018.11.04 09:00:18 5: SW: *YsAA11071A000097
2018.11.04 09:00:18 5: CUL868 sending *YsA4200A24000063
2018.11.04 09:00:18 5: SW: *YsA4200A24000063
2018.11.04 09:00:19 5: CUL868 sending *YsA0110890000008
2018.11.04 09:00:19 5: SW: *YsA0110890000008
2018.11.04 09:00:19 5: CUL868 sending *YsA6200B26000083
2018.11.04 09:00:19 5: SW: *YsA6200B26000083
2018.11.04 09:00:20 5: CUL868 sending *YsA3110B13000099
2018.11.04 09:00:20 5: SW: *YsA3110B13000099
2018.11.04 09:00:21 5: CUL868 sending *YsA3110A33000005
2018.11.04 09:00:21 5: SW: *YsA3110A33000005
2018.11.04 09:00:24 5: CUL868 sending *YsA1110A71000071
2018.11.04 09:00:24 5: SW: *YsA1110A71000071
2018.11.04 09:00:25 5: CUL868 sending *YsA7110B27000083
2018.11.04 09:00:25 5: SW: *YsA7110B27000083
2018.11.04 09:00:26 5: CUL868 sending *YsA5110A25000063
2018.11.04 09:00:26 5: SW: *YsA5110A25000063
2018.11.04 09:00:27 5: CUL868 sending *YsAA11122A000081
2018.11.04 09:00:27 5: SW: *YsAA11122A000081
2018.11.04 09:10:22 5: CUL868 sending *is0F00F0000FFF
2018.11.04 09:10:22 5: SW: *is0F00F0000FFF
2018.11.04 09:10:25 1: FHEM:DEVIO:CUL868Stack:9600 disconnected, waiting to reappear (CUL433)
2018.11.04 09:10:25 2: IT IODev device didn't answer is command correctly:   raw => No answer
2018.11.04 09:10:25 5: CUL868 sending *V
2018.11.04 09:10:25 5: SW: *V
2018.11.04 09:10:28 5: CUL868 sending *V
2018.11.04 09:10:28 5: SW: *V
2018.11.04 09:10:31 5: CUL868 sending *V
2018.11.04 09:10:31 5: SW: *V
2018.11.04 09:10:34 1: Cannot init FHEM:DEVIO:CUL868Stack:9600, ignoring it (CUL433)
2018.11.04 09:15:00 2: IT IODev device didn't answer is command correctly:   raw => No answer

Die Somfys laufen auf Homatic mit 868 oder zum Test umgestellt auf SlowRF mit dem 433 er. Beide male das gleiche Problem.

Beim alten Whezzy-System lief es ohne diese Probleme.

Anbei noch das list der CULs

--CUL433

Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        FHEM:DEVIO:CUL868Stack:9600 4444
   DeviceName FHEM:DEVIO:CUL868Stack:9600
   FD         52
   FHTID      4444
   IODev      CUL868Stack
   IODevPort  9600
   IOReadFn   STACKABLE_IOReadFn
   NAME       CUL433
   NR         736
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-10-31 13:52:43   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB
     2018-11-04 12:03:09   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2018-11-04 12:30:00   raw             is0000F0000FF0
     2018-11-04 12:03:09   state           Initialized
Attributes:
   model      CUL
   rfmode     SlowRF
   room       System->Hardware

--CUL868
   
   
   Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   CUL868_MSGCNT 6
   CUL868_TIME 2018-11-04 12:06:34
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00@38400 1444
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_4e0dfe69-if00@38400
   FD         52
   FHTID      1444
   NAME       CUL868
   NR         734
   NR_CMD_LAST_H 7
   PARTIAL   
   RAWMSG     A0EAE800254376EABCDEF010100004307
   RSSI       -70.5
   STACKED    CUL868Stack
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 868MHz)
   initString X21
Ar
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-10-31 13:53:07   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-11-04 12:03:09   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2018-11-04 00:45:22   raw             *is01101111110000000111111101000011
     2018-11-04 12:06:34   state           Initialized
   XMIT_TIME:
     1541329586.79432
     1541329590.16707
     1541329590.3421
     1541329590.8361
     1541329590.88079
     1541329592.05545
     1541329594.4262
   helper:
     54376E:
       QUEUE:
     569CC7:
       QUEUE:
     62CA70:
       QUEUE:
     62D296:
       QUEUE:
Attributes:
   hmId       ABCDEF
   model      CUL
   rfmode     HomeMatic
   room       System->Hardware
   verbose    5


Am Rpi3 hängen aktuell ein MAPLE und ein original LaCrosse dran. Da war beim alten Rpi2+ aber genau so.
Der Maple ist einer aus Arnd seinem fundus.

Danke und Grüße,
Dirk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 04 November 2018, 18:42:49
Klingt nach einem Problem mit der Stromversorgung.
Zum Testen mal ein stärkeres Netzteil oder einen aktiven hub verwenden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Devender am 05 November 2018, 12:21:40
Das sagte Arnd auch gestern.
Habt ihr empfehlungen fuer ein staerkeres Rpi Netzteil?
Fuer den dauerbetrieb eines Hubs fehlt mir an der Stelle eine Steckdose  :-[
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 05 November 2018, 13:00:18
K.A., ich nutze u.a. auch deswegen keinen Pi mehr. Es kommt nämlich u.U. auch dann noch nicht genügend Strom über USB, wenn man da nachbessert...
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 05 November 2018, 15:58:01
Hi,
Gibt es auf dem Pi 3 auch noch den Bootparameter für mehr Strom am Pi USB?
https://www.elektronik-kompendium.de/sites/raspberry-pi/2206111.htm
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dkreutz am 05 November 2018, 19:29:58
Zitat von: Devender am 05 November 2018, 12:21:40
Das sagte Arnd auch gestern.
Habt ihr empfehlungen fuer ein staerkeres Rpi Netzteil?
Fuer den dauerbetrieb eines Hubs fehlt mir an der Stelle eine Steckdose  :-[
Das Original Raspberry Pi Netzteil (https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md) - liefert 2,5A und 5,1V(!)

Zitat von: RaspiLED am 05 November 2018, 15:58:01
Hi,
Gibt es auf dem Pi 3 auch noch den Bootparameter für mehr Strom am Pi USB?
https://www.elektronik-kompendium.de/sites/raspberry-pi/2206111.htm
Wenn ich mich richtig erinnere, ist diese Begrenzung beim Pi3 aufgehoben bzw. der max_usb_current Parameter nicht mehr erforderlich.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 11 November 2018, 18:08:11
Hab gerade nach etwas hin- und her den Bootloader flashen können  :)

Hab das nach der Anleitung gemacht:
https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/MapleCUN

Kann es sein, dass da Hinweis fehlt, dass zum Flashen des Bootloaders PB2 auf Ground gezogen werden muss? Hat damit zumindest dann funktioniert bei mir.
Quelle: https://wiki.stm32duino.com/index.php?title=Burning_the_bootloader

Jumper the Boot1/PB2/D2 pin to ground.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 11 November 2018, 18:17:51
Dass PB2 auf Masse gezogen werden muss ist im Schaltplan auf der ersten Seite enthalten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 11 November 2018, 19:01:42
Ahh ok verstehe. Sorry, da hatte ich noch gar nicht reingeschaut, da ich erstmal den Maple befüllen wollte.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Devender am 12 November 2018, 12:47:10
Zitat von: dkreutz am 05 November 2018, 19:29:58
Das Original Raspberry Pi Netzteil (https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md) - liefert 2,5A und 5,1V(!)
Wenn ich mich richtig erinnere, ist diese Begrenzung beim Pi3 aufgehoben bzw. der max_usb_current Parameter nicht mehr erforderlich.

Ich melde mich mal nach dem Wochenende Testzeitraum zurueck.
Der USB Hub wurde nicht erkannt. Liegt wohl ab USB 3.0.

Ich habe aber dann trotzdem mal den Hinweis verfolgt mit dem Bootparameter .
Und es hat funktioniert. Nach dem Reboot habe ich nach und nach den Maple, Signalduino und LaCrosse angeschlossen.
Die Geraete laufen jetzt ohne die staendigen disconnects.

Danke!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: erotikbaer am 13 November 2018, 21:52:52
hi,
ich verzweifle gerade beim flashen der aculfw auf meinen maple.
das flashen des bootloaders mit usb/ttl hat geklappt, aber wenn ich versuche mit dfu-util die aculfw zu flashen bekomme ich immer:
"Cannot open DFU device 1eaf:0003"
habe es mit dem Script gemacht und auch per hand probiert.

ich schließe den maple per usb am pc an (windows) und drücke dann reset, während er blinkt (sind ca 2 sekunden) führe ich dfu-util aus bzw das script läuft bereits wenn ich ihn ranstecke.

kann mir jemand helfen?

aktualisierung: durch neuinstallieren der treiber bin ich einen schritt weiter gekommen.
folgendes kommt jetzt beim flashen:
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [======================== ]  96%        65536 bytesInvalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Error sending completion packet


gruß christian
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: erotikbaer am 13 November 2018, 22:33:20
ich komme vorran :)
anscheinend hat das flashen geklappt.

jetzt bin ich beim anlegen in fhem. und ich komme mit den wiki einträgen absolut überhaupt nicht klar.
ich habe (in der reihenfolge) folgende chips dran: 868mhz,433mhz,868mhz,868mhz
den ersten möchte ich für MAX nutzen
den 433 als 433
den dritten möchte ich für HM nutzen
und der 4. ist reserve

kann mir jemand sagen was ich da als define machen muss? ich blicks einfach nicht...
der maple wird bei mir als /dev/cuau0,   /dev/cuaU2,    /dev/cuaU3,   /dev/cuaU4 erkannt

wäre echt super wenn mir jemand helfen könnte
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 13 November 2018, 22:43:29
Hmmm, das sind eigentlich drei Devices und du brauchst nur das erste ! (Die anderen drei Tranceiver werden in FHEM als "stackable" angelegt.


Also zuerst den ersten Transceiver in FHEM einbinden und zum Laufen bekommen (egal mit welcher Betriebsart), dann geht erst weiter mit den Stackable Sachen siehe Wiki. Die weiteren Devices brauchst du nicht. Die wären um die UARTs anzusprechen.


PS:  Welches Betriebssystem ist das mit solchen Devicenamen ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: erotikbaer am 13 November 2018, 22:49:24
das ist freebsd.

aber jetzt, ohne lange erklärung... ich habs... zumindest läuft jetzt der erste.
ich versuche mich jetzt mal mit dem stackable.

gruß christian
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: erotikbaer am 14 November 2018, 00:11:29
ok, das mit dem Stackable verstehe ich nicht...
ich habe folgendes Define gemacht:
define MAPLE1_HM CUL /dev/cuaU0@38400 2143

das funktioniert auch, wenn ich den rfmode auf slowrf setze kann ich funksteckdosen schalten.

da dies jedoch der 868 chip ist, möchte ich damit homematic schalten, daher setze ich rfmode auf homematic.
wie komme ich jetzt an den nächsten funkchip (433)?

und an die nachfolgenden beiden 868 chips.

ich wäre soooooo dankbar wenn mir da jemand die defines zeigen könnte, damit ichs vielleicht verstehe
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 14 November 2018, 05:27:10
...steht im wiki zum MapleCUx...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 14 November 2018, 06:17:05
Zitat von: erotikbaer am 14 November 2018, 00:11:29

define MAPLE1_HM CUL /dev/cuaU0@38400 2143

[...]
wie komme ich jetzt an den nächsten funkchip (433)?

und an die nachfolgenden beiden 868 chips.

ich wäre soooooo dankbar wenn mir da jemand die defines zeigen könnte, damit ichs vielleicht verstehe

define MAPLE2_433 STACKABLE_CC MAPLE1_HM
define MAPLE3_MAX STACKABLE_CC MAPLE2_433
define MAPLE4_868 STACKABLE_CC MAPLE3_MAX


Angelehnt an:
https://wiki.fhem.de/wiki/MapleCUN

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 14 November 2018, 06:25:31
...bei mir läuft der Maple mit STACKABLE (ohne CC) nach der verlinkten Anleitung...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 14 November 2018, 07:45:47
Ja, geht auch!
Ist aber inzwischen beides da erklärt ;-)
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 14 November 2018, 19:42:29
Ich habe meinen MapleCUN heute mit einem W5500 ausgestattet. Wie kann ich denn testen ob das Ethernet jetzt funktioniert? Eine IP scheint er irgendwie vom Router nicht zu bekommen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 14 November 2018, 19:59:36
Alte Firmware drauf die am Debug Port Meldungen ausgibt, und mit dem Beispiel in einem der beiden Wiki Artikel vergleichen...

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: erotikbaer am 15 November 2018, 01:46:13
Zitat von: RaspiLED am 14 November 2018, 06:17:05
define MAPLE2_433 STACKABLE_CC MAPLE1_HM
define MAPLE3_MAX STACKABLE_CC MAPLE2_433
define MAPLE4_868 STACKABLE_CC MAPLE3_MAX


Angelehnt an:
https://wiki.fhem.de/wiki/MapleCUN

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Vielen Dank! Jetzt läuft alles!

Gesendet von meinem SM-N950F mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 15 November 2018, 07:37:24
Jetzt muss ich doch mal blöd fragen. Ich hatte meinen MapleCUL ja schon am laufen, also ein Bootloader und Firmware sind drauf.

Jetzt wollte ich unter Windows 7 eine ältere Firmware flashen um die Debug ausgaben zu bekommen, da der W5500 nicht das macht, was er soll.
Leider bekomme ich die ältere Firmware überhaupt nicht auf den CUL.

Ich sehe 3 MapleCUL Geräte im Windows 7 allerdings wird kein Treiber gefunden.

Kann mich bitte jemand in die richtige Richtung schubsen.

Probiert habe ich es schon mit

dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin

allerdings kommt da immer nur:

C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win>dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Lost Device after reset, assuming prod_id was incremented by oneNo DFU capable USB device found


Ich hätte auch noch einen CP210x da, falls es hilft.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 November 2018, 07:54:03
Du hast nur ca. eine Sekunde Zeit in der der Bootloader läuf. Anschliessend startet er ja die Firmware und dann ist es zu spät. Ich bekomme das ((meist)) nicht hin und nutze daher ein Skript mit einer Schleife welches ständig versucht zu flashen. (Gibt es auch im Wiki (https://wiki.fhem.de/wiki/MapleCUN#Firmware_.2F_Flashen))

Fehlerquellen sehe ich zwei (drei):
(-Firmware für W5000 geflasht)
-LAN Buchse schlecht verlötet => nachlöten
-LAN Chip wird gar nicht erkannt => LAN Modul kaputt oder die Verbindung zu diesem, oder nicht wirklich stabile 5V am Maple

Die alte Firmware zeigt hier ob das LAN Modul erkannt wurde:
ZitatWIZCHIP Initialized success.
Quelle: https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres (https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres)

PS: Unter Windows... kann funktionieren...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 15 November 2018, 08:26:05
Okay ich bin einen Schritt weiter. Wenn man kurz nach dem "Reset" rücken, den anderen Button "but=32" drückt, blinkt der Maple im 4Hz takt weiter und bleibt im DFU Modus

C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win>dfu-util --list
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=0, name=""
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000"
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000"


Danach den Treiber für den Maple setzen mit Zadig auf

libusbK (v3.0.7.0)

Danach die Firmware flashen:

C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win\dfu-util-0.9-win64>dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCU
Nx4_W5500_BL.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [=========================] 100%        66288 bytes
Download done.
Sent a total of 66288 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!





Ich habe meine Erfahrungen mal im Wiki verewigt.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 15 November 2018, 08:52:53
Moin,

Cool das kann man doch auch so und Wiki packen für Windows Nutzer ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 15 November 2018, 08:55:02
Zitat von: RaspiLED am 15 November 2018, 08:52:53
Moin,

Cool das kann man doch auch so und Wiki packen für Windows Nutzer ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk

Habe ich gerade gemacht. Hab festgestellt ich habe seit 1/2 Jahr einen Wiki Zugang.


Mit meinem Ethernet Problem bin ich allerdings nicht weiter gekommen:


-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Sep 18 2017 20:28:11 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00  VER 0x18
-I- Detected CC1: PN 0x00  VER 0x14
-I- Not detected CC2: PN 0x00  VER 0x00
-I- Not detected CC3: PN 0x00  VER 0x00
-I- Not detected ethernet
-I- Not detected onewire
-I- init USB
-I- init Complete


Die LED am W5500 leuchtet allerdings.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 November 2018, 09:01:28
ZitatMit meinem Ethernet Problem bin ich allerdings nicht weiter gekommen:

Ich denke doch...

A) Dein Netz hat ein Problem (das wüsstest du ?)
B) Einfach mal am LAN Modul die Pins zur LAN Buchse schön nachlöten
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 15 November 2018, 09:08:34
Ich hab leider keinen Lötkolben hier, aber die Lötstellen sehen alle gut aus.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 November 2018, 09:14:56
Falls Lötstellen, dann die vom letzen Foto, hinter dem Blechkasten ca 12 Pins. Das hatte ich nicht nur einmal.

Noch ne Idee: Ob das Teil einem Cross-Kabel an einen alten LAN-Switch laufen würde glaube ich übrigens nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 15 November 2018, 09:16:57
Ich nutze eine halbwegs neuen Gigabit Ethernet Switch. Dich denke da sollte autocrossover drin sein. Ich probier es heute Abend mal mit dem Lötenkolben.

Zur Not kommt das Ding erstmal aufs Steckbrett und wird mit einem Arduino getestet.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 15 November 2018, 11:39:08
-I- Not detected ethernet

Wenn diese Meldung kommt, liegt der Fehler in der Kommunikation zwischen Maple und Wizchip.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 15 November 2018, 11:45:44
Zitat von: Telekatz am 15 November 2018, 11:39:08
-I- Not detected ethernet

Wenn diese Meldung kommt, liegt der Fehler in der Kommunikation zwischen Maple und Wizchip.

Das konnte ich mir schon denken. Also liegt es weniger an den Lötstellen der Ethernet Buchse.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 15 November 2018, 17:32:08
Das mit den Lötstellen hatte ich eben auch. Keine Netzwerkverbindung. Habe dann die erwähnten Lötstellen nachgelötet und schon hat er sich eine IP geholt...


Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 November 2018, 18:17:56
Zitat von: Telekatz am 15 November 2018, 11:39:08
-I- Not detected ethernet
Wenn diese Meldung kommt, liegt der Fehler in der Kommunikation zwischen Maple und Wizchip.

Oh, da hab ich schlampig gelesen... Sorry.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 15 November 2018, 19:04:27
Was kann man denn machen, wenn das gute Ding trotzdem keine IP bekommt?
Funktionieren die Befehle Ria und Rid auch wenn die Kommunikation mit dem W5500 nicht funktioniert?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 15 November 2018, 23:29:51
Mag vielleicht ne blöde Frage sein, aber was solls  8)

Auf welche Seite der Large-Platine wird der Maple am besten gelötet? Ich hätte ihn eigentlich so gelötet, dass die USB-Buchse in der Aussparung der Platine versinkt. So wie hier auf dem Bild aus dem Wiki:
https://wiki.fhem.de/wiki/Datei:4-fach-1.3-LAN.jpg

Gibt offenbar aber auch die Variante, ihn auf die andere Seite zu löten (https://wiki.fhem.de/wiki/MapleCUX-Platinen)
https://wiki.fhem.de/wiki/Datei:4-fach-1.3-1280.jpg


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 16 November 2018, 09:34:49
Zitat von: gloob am 15 November 2018, 19:04:27
Was kann man denn machen, wenn das gute Ding trotzdem keine IP bekommt?
Funktionieren die Befehle Ria und Rid auch wenn die Kommunikation mit dem W5500 nicht funktioniert?
Wenn die Kommunikation zwischen Maple und W5500 nicht funktioniert, dann nützt dir auch eine IP Adresse nichts. Was sollen die Befehle Ria und Rid denn machen, wenn der W5500 nicht angesprochen werden kann?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 16 November 2018, 09:45:59
Zitat von: vbs am 15 November 2018, 23:29:51
Mag vielleicht ne blöde Frage sein, aber was solls  8)

Auf welche Seite der Large-Platine wird der Maple am besten gelötet? Ich hätte ihn eigentlich so gelötet, dass die USB-Buchse in der Aussparung der Platine versinkt. So wie hier auf dem Bild aus dem Wiki:
https://wiki.fhem.de/wiki/Datei:4-fach-1.3-LAN.jpg

Gibt offenbar aber auch die Variante, ihn auf die andere Seite zu löten (https://wiki.fhem.de/wiki/MapleCUX-Platinen)
https://wiki.fhem.de/wiki/Datei:4-fach-1.3-1280.jpg

Also das kommt, glaube ich auf die Version der Platine an. Ich hab die 3.3 und da macht es Sinn den Maple von unten zu löten. Sind ja auch zwei Löcher drin in der Platine über den Buttons, damit diese noch betätigt werden können. Zudem muss man das, glaube ich jedenfalls, auch so rum löten, wenn man ein Netzwerkadapter drauf macht. Bei meinem test habe ich den Maple von unten gesockelt, würde ich bei der nächsten auch nicht mehr machen.

gruß

markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 16 November 2018, 12:07:18
Zitat von: vbs am 15 November 2018, 23:29:51
Auf welche Seite der Large-Platine wird der Maple am besten gelötet? Ich hätte ihn eigentlich so gelötet, dass die USB-Buchse in der Aussparung der Platine versinkt.

Ja, das ist am besten.

Nachteil: Wenn man die Pinheader mit samt dem Plastik verlötet, dann muss man bei dem Kaufgehäuse evtl. 1mm (Kunststoff!) Unterlagsscheiben unter der Platine verwenden.
Beim gedruckten Gehäuse sollte das kein Problem sein.

PS: Beim Löten sollte man sowieso immer vor dem Löten alle Pins exakt bündig abschneiden ergibt eine gute Unterseite die man auf den Tisch legen kann ohne Kratzer und erpart der Lötstelle die Schockwelle... Das spart dann auch hier so ca. 2mm Höhe, aber das reicht nicht unbedingt für eine spannungsfreie Montage. Übergründliche Leute entfernen daher das Plastik vom Pinheader (mir ist das zu viel Arbeit).



Wenn niemals LAN gebraucht wird evtl oben.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 16 November 2018, 16:01:35
Ok klasse, danke euch. Wieder was gelernt... Dann werde ich das Ding da nachher mal drauf nageln...  :-X
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 16 November 2018, 16:33:19
Apropos dazugelernt: libusb (https://fishpepper.de/2016/09/02/using-dfu-to-flash-stm32-f2-f3-f4-flight-controller-on-windows-and-linux/)  ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 19 November 2018, 16:36:28
Heute kam ein neuer W5500. Drauf gesteckt auf den Sockel und es geht ohne Probleme. Scheinbar hatte der erste einen Knacks weg.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 19 November 2018, 17:37:20
Ich würde wetten meine beiden haben den gleichen Fehler. Willst du den Fehler finden ? 8)
(Dann kannst du meine beiden haben...)
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 19 November 2018, 17:42:26
Kannst du mal bitte Bilder von deinem Modul zeigen? Scheint ja 2 unterschiedliche bei AliExpress zu geben.

Ich hab aktuell das hier: (https://uploads.tapatalk-cdn.com/20181119/e4b1edd6989c6adf1e3433f48f1438fe.jpg)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 19 November 2018, 17:47:40
Weiß nicht mehr, ob es diese LAN-Modultype war, aber vielleicht sucht ihr mal, könnte ein falscher Widerstandswert sein...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 19 November 2018, 19:11:31
Hm ich bin ja noch recht frischer Besitzer eins CUL und bin noch in der Aufbauphase. Aber ich hab momentan das Problem, dass sich das Ding alle paar Stunden komplett weghängt. Ich vermute, dass der Maple selber hängt. Es hilft dann nur, den USB-Stecker einmal zu ziehen und wieder zu stecken.

Ich hab momentan einen C1101 und den HM-MOD-UART dran und beide sind im Falle des Hängers nicht mehr erreichbar (daher vermute ich Maple selbst).

Woran kann sowas liegen? Stromversorgung ist oft ein Problem bei sowas, oder? Ich bin da sicherlich recht hemdsärmlig unterwegs: ich hab das bisher alles nur mit Kabel gesteckt und laut Schaltplan gehört da ja wohl auch noch der eine oder andere Kondensator auf die Platine. Die fehlen mir auch noch. Ist das evtl. schon eine mögliche Ursache?

Firmware hab ich die aktuellste acul drauf. Betreibe die Platine normal mit USB-Kabel an einem Mini-PC.

Sieht so aus:
https://imgur.com/a/jbsP8LS
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 19 November 2018, 19:33:28
Tipp: 40-100uF Kondensator zum Stützen und mit gut 5V speisen, 5,2 oder 5,3V sind im Zweifelsfall besser als 4,8V über langes dünnes Kabel.

Von wo ganz genau kommt der Saft?
(Bei Problemen bitte niemals von Raspi, Router oder sonstwas...)
Damit mir der Maple sympathisch wäre, würde ich einen Bate-Aufdruck erwarten. Wenn er auch ohne stabil läuft: Glückwunsch 8)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 19 November 2018, 19:37:50
Zitat von: gloob am 19 November 2018, 17:42:26
Kannst du mal bitte Bilder von deinem Modul zeigen? Scheint ja 2 unterschiedliche bei AliExpress zu geben.

Ich hab aktuell das hier: (https://uploads.tapatalk-cdn.com/20181119/e4b1edd6989c6adf1e3433f48f1438fe.jpg)

Ich habe vor allem solche. Ich hatte auch mal ein paar die schon an der Farbe des Pinheaders zu erkennen waren. Da waren 30% Defekt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 20 November 2018, 11:56:06
Zitat von: Ranseyer am 19 November 2018, 19:33:28
Tipp: 40-100uF Kondensator zum Stützen und mit gut 5V speisen, 5,2 oder 5,3V sind im Zweifelsfall besser als 4,8V über langes dünnes Kabel.
Ok danke, das werd ich mal machen!
Eine Frage: Der Kondensator, den du meinst, entspricht auf der Platine C5, oder? C5 ist in Eagle (https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Archiv/V3.3/mapleCUx_large_330-014.sch) mit 220uF angegeben. Hier in der partlist.txt (https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/partlist.txt) mit 10uF. Also ziemlich verschiedene Angaben. Oder ist der Wert am Ende gar nicht sooo wichtig?

Zitat von: Ranseyer am 19 November 2018, 19:33:28
Von wo ganz genau kommt der Saft?
Der Maple hängt mit einem 0,5m-USB-Kabel (wirkt robust) an den Front-USB-Buchsen eines Cube-PC-Gehäuses. Die Front-Buchsen gehen dann per Kabel auf die Stiftleisten des Mini-ITX-Mainboards.
Ich hab jetzt mal als Sofortmaßnahme, den Maple vom Front-USB auf eine USB-Buchse des rückseitigen Panels verlegt, das direkt mit dem Board verlötet ist. Hat komischerweise zumindest jetzt die Nacht durchgehalten... mal beobachten...

Zitat von: Ranseyer am 19 November 2018, 19:33:28
(Bei Problemen bitte niemals von Raspi, Router oder sonstwas...)
Damit mir der Maple sympathisch wäre, würde ich einen Bate-Aufdruck erwarten. Wenn er auch ohne stabil läuft: Glückwunsch 8)
Oh mann, nee einen Baite-Aufdruck hab ich nicht drauf... :/ Kannte diese Problematik gar nicht. Hab mir gerade bei Ali nochmal einen Maple von Baite bestellt für alle Fälle. Danke für die Tipps! Der Teufel ist ein Eichhörnchen...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 20 November 2018, 12:26:04
Zitat von: vbs am 20 November 2018, 11:56:06
Der Kondensator, den du meinst, entspricht auf der Platine C5
Genau. Einfach Platz für einen fetten Kondensator suchen, SMD wäre daneben, oder halt bedrahtet.

ZitatDer Maple hängt mit einem 0,5m-USB-Kabel (wirkt robust) an den Front-USB-Buchsen eines Cube-PC-Gehäuses. Die Front-Buchsen gehen dann per Kabel auf die Stiftleisten des Mini-ITX-Mainboards.
Dann würde ich bei den nächsten Problem ein brauchbares extra USB-Netzteil nehmen. (Auch wenn die direkten Buchsen evtl schon etwas besser sind...)


Den Maple tauschen würde ich erst reichlich später, und ich hoffe/glaube so weit wird das Problem nicht gehen...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 20 November 2018, 15:58:24
Ok, ist wieder passiert. Also der reine Wechsel des USB-Ports hat es nicht gebracht. Hatte ich jedoch auch nicht viel Hoffnung... Hab mir jetzt mal einen Kondensator von nem Kollegen "geliehen", den ich nachher mal verbauen werde...

Den Maple tauschen würde ich erst reichlich später, und ich hoffe/glaube so weit wird das Problem nicht gehen...
Joa, muss aber irgendwie die Latenz von Ali kompensieren ^^ Wenn ich in zwei Wochen merke, dass mein nicht Bait-Maple einfach madig ist, dann krieg ich vor Weihnachten keinen Ersatz mehr ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 21 November 2018, 18:33:09
Bei mir stürzt regelmäßig (ca. alle 12 Stunden) was ab im Maple. Dachte erst, es wäre der ganze Maple, aber da hab ich leider etwas falsch interpretiert. Es ist doch nur der HM-MOD-UART, der nicht mehr funktioniert. Sieht dann im Log so aus:

2018.11.20 15:48:41.575 3: <EVENT> sys_culHm - cond: init
2018.11.20 15:48:44.553 1: HMUARTLGW sys_culHm did not respond for the 1. time, resending
2018.11.20 15:48:47.559 1: HMUARTLGW sys_culHm did not respond for the 2. time, resending
2018.11.20 15:48:50.565 1: HMUARTLGW sys_culHm did not respond for the 3. time, resending
2018.11.20 15:48:53.571 1: HMUARTLGW sys_culHm did not respond after all, reopening
2018.11.20 15:49:25.694 3: sys_culHm device closed
2018.11.20 15:49:25.699 3: <EVENT> sys_culHm - cond: disconnected
2018.11.20 15:49:25.711 3: Setting sys_culHm serial parameters to 115200,8,N,1
2018.11.20 15:49:25.713 1: /dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if04 reappeared (sys_culHm)
2018.11.20 15:49:25.717 3: <EVENT> sys_culHm - CONNECTED
2018.11.20 15:49:25.775 2: CUL_TX Unknown device 127, please define it
2018.11.20 15:49:25.787 1: [Freezemon] sys_freezemon: possible freeze starting at 15:48:54, delay is 31.786 possibly caused by: tmr-HMUARTLGW_CheckCmdResp(sys_culHm)
2018.11.20 15:49:26.726 3: <EVENT> sys_culHm - cond: init
2018.11.20 15:49:27.168 1: CUL_WS UNDEFINED unknown sensor detected, code 8
2018.11.20 15:49:29.720 1: HMUARTLGW sys_culHm did not respond for the 1. time, resending
2018.11.20 15:49:32.723 1: HMUARTLGW sys_culHm did not respond for the 2. time, resending
2018.11.20 15:49:35.730 1: HMUARTLGW sys_culHm did not respond for the 3. time, resending
2018.11.20 15:49:38.737 1: HMUARTLGW sys_culHm did not respond after all, reopening
2018.11.20 15:50:10.667 3: sys_culHm device closed
2018.11.20 15:50:10.672 3: <EVENT> sys_culHm - cond: disconnected
2018.11.20 15:50:10.684 3: Setting sys_culHm serial parameters to 115200,8,N,1
2018.11.20 15:50:10.688 1: /dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if04 reappeared (sys_culHm)
2018.11.20 15:50:10.692 3: <EVENT> sys_culHm - CONNECTED
2018.11.20 15:50:10.703 2: CUL_TX Unknown device 127, please define it
2018.11.20 15:50:10.761 1: [Freezemon] sys_freezemon: possible freeze starting at 15:49:39, delay is 31.76 possibly caused by: tmr-HMUARTLGW_CheckCmdResp(sys_culHm)
2018.11.20 15:50:11.712 3: <EVENT> sys_culHm - cond: init
2018.11.20 15:50:14.695 1: HMUARTLGW sys_culHm did not respond for the 1. time, resending
2018.11.20 15:50:17.698 1: HMUARTLGW sys_culHm did not respond for the 2. time, resending
2018.11.20 15:50:20.702 1: HMUARTLGW sys_culHm did not respond for the 3. time, resending
2018.11.20 15:50:23.707 1: HMUARTLGW sys_culHm did not respond after all, reopening
2018.11.20 15:50:55.691 3: sys_culHm device closed


Ich hab jetzt versucht, den HM-MOD-UART zu rebooten, indem ich sein VCC+GND vom Maple abgezogen und wieder drauf gesteckt habe. Das hat aber nichts gebracht. FHEM restart bringt auch nix. Es funktioniert erst wieder, wenn ich den Maple vom USB ziehe und wieder dran stecke - also den Maple reboote.
Das parallel auf dem Maple laufende 433 MHz funktioniert während der Zeit wunderbar weiter.

Sieht fast so aus, also ob gar es nicht HM-MOD-UART selbst liegt, sondern "nur" an dieser seriellen Weiterleitung bzw. dem seriellen Gerät "/dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if04" im Maple, oder? Wenn es am HM-MOD-UART liegen würde, hätte doch die VCC/GND-Methode helfen müssen?

Hat da jemand ein Idee?

Das ist mein (Test)Aufbau:
https://imgur.com/a/jbsP8LS

EDIT:
Achso, nochmal mit verbose-5-Log
2018.11.21 18:41:37.785 4 : HMUARTLGW sys_culHm StartInit
2018.11.21 18:41:37.786 5 : HMUARTLGW sys_culHm send: 00 00
2018.11.21 18:41:37.786 5 : HMUARTLGW sys_culHm send: (8): fd00030001009e03
2018.11.21 18:41:37.786 5 : SW: fd00030001009e03
2018.11.21 18:41:37.793 3 : <EVENT> sys_culHm - cond: init
2018-11-21 18:41:37.799 HMUARTLGW sys_culHm cond: init
2018-11-21 18:41:37.803 CUL_HM VCCU HMLAN0:ok,sys_culHm:init,
2018.11.21 18:41:40.787 1 : HMUARTLGW sys_culHm did not respond for the 1. time, resending
2018.11.21 18:41:40.788 5 : HMUARTLGW sys_culHm send: (8): fd00030001009e03
2018.11.21 18:41:40.788 5 : SW: fd00030001009e03
2018.11.21 18:41:43.794 1 : HMUARTLGW sys_culHm did not respond for the 2. time, resending
2018.11.21 18:41:43.794 5 : HMUARTLGW sys_culHm send: (8): fd00030001009e03
2018.11.21 18:41:43.794 5 : SW: fd00030001009e03

Sieht aus, als gäbe es da einfach keinerlei Kommunikation mehr.

Das ist der CUL:
V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) MapleCUNx4_01 (F-Band: 433MHz)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 21 November 2018, 19:06:37
Hast du den Tipp mit dem Kondensator befolgt? Was nutzt du als Spannungsversorgung?

Wenn der HM-MOD-UART kurz zu wenig Spannung bekommt, bricht die Verbindung zwischen Maple und Modul ab und muss erst wieder neu "aufgebaut" werden. Dafür wird denke eine "Initialisierung" notwendig sein, die nur beim Neustarten des Maple passiert.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 21 November 2018, 19:21:27
Ja, Kondensator ist dran, jedoch nur 22uF. Hab gerade nochmal auf 100uF upgegradet. Kann aber nicht wirklich einschätzen, wie hoch die Chancen sind, dass es daran liegt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 21 November 2018, 19:25:06
Schwer zu sagen. Solange ist nicht sauber läuft würde ich:
-gutes USB Netzteil
-mindesten 100uF nehmen.
Wenn es läuft kannst du ja abrüsten.

(100uF ist beim Raspi Homematic Adapter für den HM_Mod-UART auch dabei, Achtung Tantal = ggf. kleine Bombe falls verpolt)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 21 November 2018, 22:56:18
Ok, Danke für die Tipps!

Hab jetzt:
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 22 November 2018, 17:38:33
Hab da ein seltsames Problem beim Umstieg der Definition auf STACKABLE.
Getestet habe ich vorher mit STACKABLE_CC und da ist alles soweit gelaufen. Dann habe ich alle Devices mit STACKABLE_CC
gelöscht und FHEM neu gestartet und folgende Definition verwendet.


define MAPLECUN_0_868 CUL 192.168.178.21:2323 4444


define MAPLECUN_0_868Stack STACKABLE MAPLECUN_0_868
define MAPLECUN_1_433 CUL FHEM:DEVIO:MAPLECUN_0_868Stack:9600 0000

define MAPLECUN_1_433Stack STACKABLE MAPLECUN_1_433
define MAPLECUN_2_868 CUL FHEM:DEVIO:MAPLECUN_1_433Stack:9600 0000

define MAPLECUN_2_868Stack STACKABLE MAPLECUN_2_868
define MAPLECUN_3_868 CUL FHEM:DEVIO:MAPLECUN_2_868Stack:9600 0000


Die devices werdn auch als initialized angezeigt. Dann habe ich ein bei einem IT Stecker das IO Device auf den Maple (433) umgestellt und danach hängt FHEM komplett. Nur ein Neustart des Raspis hilft da und der dauert dann auch ewig lange.

Wie gesagt mit STackable_CC habe ich dieses Problem nicht.

Hoffe da hat einer eine Idee..

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 23 November 2018, 08:35:21
Und noch ne Frage, da ich gerne viel austeste ;-)

Die Platine kann ja auch Homematic mit einem CC1101 868MHz, worin liegt der da der Vorteil Wenn man einen HMUart zusätzlich verbaut? Erschlagt mich nicht direkt wenn das irgendwo steht und ich es überlesen haben sollte ;-)
Macht das nur Sinn wenn man alle 868 Radios bereits anderweitig nutzt?
Mit der letzten Firmware-Version werden ja auch Lacrosse erkannt als Homematic devices oder...?!?

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dkreutz am 23 November 2018, 09:21:31
Zitat von: Markus. am 23 November 2018, 08:35:21
Die Platine kann ja auch Homematic mit einem CC1101 868MHz, worin liegt der da der Vorteil Wenn man einen HMUart zusätzlich verbaut? Erschlagt mich nicht direkt wenn das irgendwo steht und ich es überlesen haben sollte ;-)
Macht das nur Sinn wenn man alle 868 Radios bereits anderweitig nutzt?
HM-UART ist "das Original", bei CC1101+(a)culfw ist das Protokoll reverse-engineered. Ob sich das praktisch auswirkt hängt von vielen Faktoren ab.

Zitat von: Markus. am 23 November 2018, 08:35:21
Mit der letzten Firmware-Version werden ja auch Lacrosse erkannt als Homematic devices oder...?!?
Ja, LaCrosse über CC1101-868 wird erkannt, aber nicht als Homematic sondern HMS. (Wenn Du bisher einen JeeLink-CUL hattest, dann musst Du alle LaCrosse-Devices neu als HMS-Device anlegen (bzw. werden durch autocreate neu angelegt).
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 23 November 2018, 09:27:01
danke dir erstmal für die Antwort...
Nun muss ich nur noch dieses seltsame STACKABLE(_CC) Problem in den griff bekommen.

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 23 November 2018, 11:47:53
So wie ich das bzgl. Homematic verstehe, sind die Timings des Protokolls ein großes Problem. Gibt dafür einen eigenen Fork der cul-FW, die das wohl schon besser beherrscht. Aber wohl auch nicht perfekt. Daher wird von vielen empfohlen, für Homematic immer ein original HM-IO-Device zu benutzen (also z.B. HM-MOD-UART). Da kümmert sich dann dieses Device selbst um das Einhalten der Timings. So zumindest mein Verständnis.


Zu meinen Abstürzen:
Also das scheint momentan stabil zu laufen: 2 Tage ohne Abstürze. Werde es weiter beobachten, aber scheint nun stabil zu sein. Ich habe momentan einen 100uF Kondensator dran und zusätzlich ein externes USB-Netzteil.
Eigentlich würde ich das externe Netzteil gerne wieder los werden. Ist schon sexy, wenn das Ding direkt vom PC per USB-Kabel gepowert wird. So wie ich das sehe, ist Kondensator C5 im Schaltplan mit 220uF angegeben. Macht es Sinn auszuprobieren, das USB-Netzteil wegzulassen und dafür den 100uF durch 220uF zu ersetzen?

Das Ganze würde dann bei mir in der Kategorie "Viel hilf viel!" laufen  :-X
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 23 November 2018, 12:08:48
Zitat220uF zu ersetzen?
Die Zahl ist von mir. Ich hätte das Feld leer lassen können. Statt dessen habe ich halt 220uF vorgesehen. Ich verbaue meist 47uF. (Und nutze nur noch gute USB-Netzteile. Der CUL in der Garage wird vom Router gespeist, aber nur weil es halt zufällig funktioniert)

Das Problem ist doch auch dass dir keiner sagen kann welche Spannung an Deiner USB Buchse wirklich noch anliegt wenn diese belastet wird. Zweitens: die Qualität der Spannung = Restwelligkeit unter Last = ???
Falls du die Speisung über die Hohlbuchse machst wäre z.B. ein dickeres Kabel denkbar, und auch das kann notfalls an einem USB-A Stecker enden...
Was sicher nicht schadet: ein kleiner Keramik-Kondensator zusätzlich am Eingang um evtl. hochfrequente Sachen kurzzuschliessen. Kann ja sein dass Du Powerline oder anderes Zeug in der Nähe hast.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 23 November 2018, 12:21:30
Ok, danke für die Tipps! Muss zugeben, dass mich das schon an die Grenzen meiner bescheidenen Elektro-Kenntnisse bringt...
Ich hab an dem gleichen Rechner bisher einen HM-USB-CFG2 und einen RfxTrx433 per USB betrieben und das war problemlos. Ist sicherlich nicht dasselbe wie der Maple aber ich würde hoffen zumindest vergleichbar.
Also ich werde da mal einfach etwas rumprobieren mit Kondensatoren und Kabel usw. Der Baite-Maple ist ja auch unterwegs. Evtl. ist der ja auch etwas stabiler bzgl. Spannunsgschwankungen. Der wird aber sicherlich noch ein paar Wochen unterwegs sein. Blöd, dass ich wohl besser mit dem Löten auf die Platine warten sollte, bis das alles geklärt ist  :-\
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 23 November 2018, 16:10:16
Ja klasse, ist doch wieder passiert... kaum hat man's gesagt  >:(

Aber eine neue Erkenntnis: ich hab jetzt ja am Maple eine externes USB-Netzteil, so dass der Maple weiter läuft (nicht gepowercyclet wird), wenn ich den normalen USB-Stecker abziehe. Und interessanterweise ist es so, dass der Maple wieder funktioniert (also ich wieder per seriell mit dem HM-MOD-UART reden kann), wenn ich USB einmal abziehe und wieder dran stecke!
Also was sich offenbar nur aufhängt, ist die USB-Verbindung an sich (dieses Device /dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if04).
Ich ziehe momentan in Betracht, dass es gar nix mit der Spannungsversorgung zu tun hat.

Das Ding bietet ja in Linux drei serielle Devices an. Es betrifft nur das Device, über den der HM erreichbar ist (/dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if04). Das "normale" Device, mit dem der 433-CUL bedient wird (/dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if00), läuft dauerhaft durch.
Könnte also auch ein Firmware-Bug in der aculfw sein? Oder ein Problem mit meinem Linux? Oder was ganz anderes... Vielleicht frage ich mal drüben im aculfw-Thread...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 25 November 2018, 10:48:10
Also ich hab über WLAN/RJ45 keine Probleme mit dem MapleCUN und ich habe auch Homematic und gleichzeitig noch MAX mit scanner am laufen. USB nutze ich nicht in meinem Produktivsystem da kann ich nur sagen das es funktioniert wenn ich ihn anstecke. Wie lang das stabiel läuft weiß ich aber nicht. Ich habe mal gemessen das mein MapleCUN im leerlauf 250mA zieht. Um Stromspitzen beim senden zu messen habe ich leider kein Messgerät für. aber mit einem Noname 500mA Netzteil gibt es keine Probleme. Was ich weiß ist das es wohl Probleme mit Schnelladegeräten gibt wie Apple sie z.B. meist zu Handys zu legt da diese nur dann Strom liefern wenn dem Netzgerät ein Chip sagt was es tun soll. Mit Apple Netzgeräten habe ich definitiv Rückmeldungen bekommen das es beim Senden zum Absturz bzw neustart des MeplaCUN kommt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 25 November 2018, 11:59:05
In meinem Fall ist es so, dass der Maple nicht resettet wenn Homematic ausfällt, sondern weiter läuft. Halte es eher für unwahrscheinlich, dass der Controller wegen Spannungsproblemen aufhört, eine Schnittstelle zu bedienen. Aber ausschließen will ich nix.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Leinad am 29 November 2018, 13:35:14
Eine Frage für dummies 😀

Ich blicke nicht ganz durch.
Wie/wo wird konfiguriert an welcher Position welches Funkmodul hängt (433 / 868)? Der Wikieintrag hat mich bisschen verunsichert.
Ist es nicht so, dass die Anordnung total egal ist, solange ich die Reihenfolge beim define bzw. beim Auswählen des Funkprotokolls beachte?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 29 November 2018, 14:23:36
Ja ist richtig, aber der Werksreset Standard ist 1,3,4 auf 868 und 2 auf 433. okay die meisten Platinen zählen 0-3: 0,2,3 auf 868 und 1 auf 433
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Leinad am 29 November 2018, 14:36:26
Genau das verstehe ich leider nicht. Es sind ja beides cc1101,lediglich mit unterschiedlicher Beschaltung? Wo genau wird etwas auf Werkseinstellungen gesetzt? Dachte es ist nur die Ansteuerung aus Fhem entscheident?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 29 November 2018, 14:40:11
Der MapleCUN erkennt selbst ständig was für ein CC1101 dort hängt, es ist nicht nur die Beschaltung.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Leinad am 29 November 2018, 15:15:53
Ok, wenn er es selbstständig erkennt (und anpasst?) sind die Werkseinstellungen in dem Fall nicht relevant?
Wird diese Erkennung automatisch durchgeführt oder muss es über einen Befehl angestoßen werden?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 29 November 2018, 15:30:15
In der Firmware ist es hier definiert:
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/cc1100.c

Zeile 70, 124, 180
0x21, // 0D FREQ2    *1E    21    868.3 (def:800MHz)
0x10, // 0D FREQ2    *1E    21    433.92 (def:800MHz)

Könnte auch an noch mehr stellen festgelegt sein.

Grundlegend ist der a-culfw das egal. Beim Maple macht es aber keinen Sinn das 433MHz Modul an letzter Stelle anzuschließen da auf dem letzten Modul kein SlowRF geht. Ansonsten kann man ja jederzeit das Register des CC1101 umkonfigurieren so das die CC1101 eine andere Frequenz verwendet. Wenn man fertige Module mit Antennenbeschaltung kauft sind die CC1101 meist ab Werk für die Antennenfrequenz richtig konfiguriert.

Gruß
Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 29 November 2018, 17:11:39
Zitat von: gloob am 29 November 2018, 14:40:11
Der MapleCUN erkennt selbst ständig was für ein CC1101 dort hängt, es ist nicht nur die Beschaltung.
Doch, es ist nur die Antennenbeschaltung die sich unterscheidet. Es gibt keine unterschiedlichen CC1101 für die beiden Frequenzbereiche.
Der MapleCUN kann gar nicht erkennen, für welche Frequenz die Beschaltung des Moduls geeignet ist. Die Firmware geht immer davon aus, dass nur das zweite Modul ein 433MHz Modul ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 29 November 2018, 18:18:51

Hi,
das wird beim normalen CUL ja auch nur über einen Widerstand an einem zusätzlichen GPIO für 433 MHz markiert. Aber der Maple hat halt nix mehr frei ;-) Sonst hätte Telekatz SlowRF am 4 Radio eingebaut *lol*


Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 29 November 2018, 18:29:21
Dann habe ich das wohl mit dem SignalESP verwechselt, der erkennt per Software was angeschlossen trinken
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 29 November 2018, 20:04:21
Hi,
Ich finde das nicht, der hat auch den PIN_MARK433 drin:
https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101-serial-parse/cc1101.h

Wo erkennt er das in den Registern? Das würde Telekatz bestimmt für uns einbauen ;-)
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 30 November 2018, 09:01:05
Hallo zusammen,

ich bin gerade dabei mich in KiCAD ein zu arbeiten um meine eigenen Ideen bezüglich des MapleCUN umsetzen zu können. Mir ist aufgefallen das das W5500 Modul einen eigenen SPI Bus vom Maple mini her hat und alle 4 CC1101 an einem SPI Bus mit chip select arbeiten. Was mir dabei nicht ganz klar ist ist warum das W5500 nicht den selben SPI Bus wie die CC1101 nutzen kann. Mir ist klar das es sehr wahrscheinlich einen Grund dafür gibt nur ist er mir nicht klar. Man möge mich erleuchten.

LG Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 30 November 2018, 09:28:02
Zitat von: RaspiLED am 29 November 2018, 20:04:21
Hi,
Ich finde das nicht, der hat auch den PIN_MARK433 drin:
https://github.com/RFD-FHEM/SIGNALDuino/blob/dev-r33_cc1101-serial-parse/cc1101.h

Wo erkennt er das in den Registern? Das würde Telekatz bestimmt für uns einbauen ;-)
Gruß Arnd


Gesendet von iPhone mit Tapatalk

Ich wusste doch es gab da mal was: https://forum.fhem.de/index.php/topic,58396.msg678595.html#msg678595

Bzw: https://forum.fhem.de/index.php/topic,58396.msg690860.html#msg690860

Scheinbar war es dann doch keine zufriedenstellende Lösung und ist wieder raus geflogen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dkreutz am 01 Dezember 2018, 20:30:56
Hallo,
ich habe Probleme meinen MapleCUL (mit 3xCC1101-868 und 1xCC1101-433, HM-UART aufgelötet) stabil in Betrieb zu nehmen.
Firmware ist:
VERSION    V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) MapleCUNx4_80

CUL0:

define mCUL0_LaCrosse CUL 192.168.1.53:2323 1234
attr mCUL0_LaCrosse connectCommand Nr1
attr mCUL0_LaCrosse model CUN
attr mCUL0_LaCrosse rfmode SlowRF

funktioniert soweit gut, empfängt sogar Sensoren aus der Nachbarschaft. Es gibt aber immer wieder Eventlog-Meldung folgender Art
UNKNOWNCODE N01EFA23E3F273166A5AAAAAA00

CUL1:
define mCUL1_IT STACKABLE_CC mCUL0_LaCrosse
attr mCUL1_IT model CUN
attr mCUL1_IT rfmode SlowRF

Hat anfangs funktioniert, nach einem Reboot dann nichts mehr, liegt wohl an
ccconf freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB
Setzen der Frequenz mit "set mCUL1_IT freq 433.920" bringt nichts...

CUL2:
defmod mCUL2_MAX STACKABLE_CC mCUL1_IT
attr mCUL2_MAX model CUN
attr mCUL2_MAX rfmode MAX

Hier gab es sehr schlechte RSSI-Werte gibt (-95 aus 70cm Entfernung). Habe dann Antennen von CUL0 und CUL2 getauscht. Damit ging es erst einmal gut (die Nachbarn haben nicht nur HMS-Sensoren, sondern auch MAX-Fensterkontakte). Nach Reboot wieder das Problem mit RSSI...

CUL3 ist nicht benutzt und auch nicht in FHEM konfiguriert.
HM-UART arbeitet problemlos.

Ich bin etwas ratlos - Hardware-Problem? Stimmt meine Konfiguration in FHEM nicht? Firmware-Bug?

Viele Grüße
Dominik
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 02 Dezember 2018, 19:26:01
Ist manchmal wirklich zum Ärgern... nachdem ich jetzt nach x Tagen endlich meinem Homematic-Hänger auf die Schliche gekommen bin, sagt jetzt genau nach der finalen Inbetriebnahme mit einer potentiell gefixten Firmware, das HM-MOD-UART-Modul keinen Pieps mehr  >:(
Hab schon Anschlüsse geprüft, MapleMini getauscht, mit Oszi die seriellen Daten an den Pins des HM-MOD angeschaut... alles ok meiner Meinung nach. Also ich sehe Daten rein gehen, aber keine rauskommen.
Bleibt für mich nur übrig, dass das HM-Modul jetzt kaputt gegangen ist. Hat noch jemand eine andere Idee evtl. bevor ich jetzt Ersatz bestelle? Hatte das schonmal jemand, dass so ein Ding kaputt gegangen ist?  >:( ::)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 02 Dezember 2018, 19:35:32
Was passiert denn wenn du die vorherige Firmware wieder nutzt?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 02 Dezember 2018, 19:37:09
Achso, vergessen zu erwähnen sorry. Bin wieder zurück auf der letzten offiziellen, aber trotzdem tot.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 02 Dezember 2018, 22:25:49
Hallo,

viellelicht mal das HM-MOD-UART Modul nur an einem USB-Kontroller und dann an PC oder Raspi hängen um zu sehen was geht. Vorher eine Weile stromlos machen.

pejonp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 03 Dezember 2018, 19:11:47
Gute Idee, aber leider auch da keine Rückmeldung von dem Ding. Wusste allerdings nicht genau, was ich schicken muss, damit er antwortet. Hab mal die Daten von hier geschickt:
https://forum.homegear.eu/t/Support-f%C3%BCr-neues-Funkmodul-HM-MOD-RPI-PCB-f%C3%BCr-Raspberry-Pi/399/11
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 03 Dezember 2018, 19:42:23
Einfach per USB an den raspi7 hängen und mit dem 00_HMUARTLGW.pm Modul ansteuern. Wenn  das HM-MOD-UART Modul ok ist sollte ja etwas ankommen.

Pejonp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dkreutz am 03 Dezember 2018, 20:14:38
Ich antworte mir mal selbst:
Zitat von: dkreutz am 01 Dezember 2018, 20:30:56
Hallo,
ich habe Probleme meinen MapleCUL (mit 3xCC1101-868 und 1xCC1101-433, HM-UART aufgelötet) stabil in Betrieb zu nehmen.
Firmware ist:
VERSION    V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) MapleCUNx4_80

...Nach Reboot wieder das Problem mit RSSI...

Ich bin etwas ratlos - Hardware-Problem? Stimmt meine Konfiguration in FHEM nicht? Firmware-Bug?

Für das Reboot-Problem habe ich jetzt einen halbwegs funktionierenden Workaround: MapleCUL aus (Netzteil ziehen), FHEM shutdown restart, MapleCUL wieder an.
Gibt es eine Möglichkeit (z.B. per RAW-Command) den MapleCUL neu zu starten?

Es besteht immer noch das Problem mit dem 433er/IT:
Zitat von: dkreutz am 01 Dezember 2018, 20:30:56
ccconf freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB
Setzen der Frequenz mit "set mCUL1_IT freq 433.920" bringt nichts...

Weiterhin Hinweise dazu erwünscht.

Vielen Dank und Viele Grüße
Dominik
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 03 Dezember 2018, 20:18:03
Wenn die Frequenz nicht ausgelesen werden kann, funktioniert die Kommunikation mit dem Modul nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 03 Dezember 2018, 20:19:21
Hi,
Freq=0 neu verlöten ;-)
W/ dem anderen Problem ist mein Tipp: Bessere Stromversorgung!
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 03 Dezember 2018, 20:23:20
Zitat von: Eistee am 30 November 2018, 09:01:05
Hallo zusammen,

ich bin gerade dabei mich in KiCAD ein zu arbeiten um meine eigenen Ideen bezüglich des MapleCUN umsetzen zu können. Mir ist aufgefallen das das W5500 Modul einen eigenen SPI Bus vom Maple mini her hat und alle 4 CC1101 an einem SPI Bus mit chip select arbeiten. Was mir dabei nicht ganz klar ist ist warum das W5500 nicht den selben SPI Bus wie die CC1101 nutzen kann. Mir ist klar das es sehr wahrscheinlich einen Grund dafür gibt nur ist er mir nicht klar. Man möge mich erleuchten.

LG Alina
Es gibt keinen speziellen Grund.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dkreutz am 03 Dezember 2018, 20:24:57
Also ein Hardware-Problem - obwohl es ja zwischendurch schon bis zu einem Reboot funktioniert hat?

Stromversorgung läuft momentan über ein 0.5A-USB-Netzteil (nicht Ladegerät), habe noch ein 1A-Netzteil das ich ausprobieren werde...

EDIT: Habe den MapleCUL so bekommen (Bild angehängt), soll ich da nochmal nachlöten?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Dezember 2018, 11:46:48
Zitat von: dkreutz am 03 Dezember 2018, 20:24:57
EDIT: Habe den MapleCUL so bekommen (Bild angehängt), soll ich da nochmal nachlöten?

Schaden kanns nicht. Vielleicht nen kleiner Wackler drin.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 04 Dezember 2018, 14:12:44
Zitat von: dkreutz am 03 Dezember 2018, 20:24:57soll ich da nochmal nachlöten?

Da hab ich deutlich mehr Lötzinn an meinen Modulen. Und löte mal den C3 noch ein wenn du schon dabei bist. Die kleinen Viecher sind gar nicht so unwichtig. Evtl. fehlen auch noch weitere Kondensatoren die man da nicht sieht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Dezember 2018, 14:25:08
Zitat von: Eistee am 04 Dezember 2018, 14:12:44
Da hab ich deutlich mehr Lötzinn an meinen Modulen. Und löte mal den C3 noch ein wenn du schon dabei bist. Die kleinen Viecher sind gar nicht so unwichtig. Evtl. fehlen auch noch weitere Kondensatoren die man da nicht sieht.

C3 braucht es nicht, der ist doch direkt auf dem Funkmodul mit drauf.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 Dezember 2018, 14:39:40
Zitat von: Eistee am 04 Dezember 2018, 14:12:44
Da hab ich deutlich mehr Lötzinn an meinen Modulen.

Kann man machen. braucht man aber bei Lötpaste nicht.
Aber ich würde es trotzdem mal zusätzlich verlöten wenn du das sauber hinbekommst. C3 ist unnötig "siehe Gloob".
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 05 Dezember 2018, 20:50:39
Hallo zusammen,
ich habe mal eine Frage zu den Seriellen schnittstellen vom MapleCUN.
Funktionieren die auch mit dem 5500 ethernet shield?
Im Wiki steht über usb werden die bereitgestellt nicht auch über lan?

Und kann ich an eine serielle schnittstelle eine Infrarotdiode mit treibertransistor hängen und mit LIRC ansteuern?
Und an die andere einen CC2530 um zigbee zu ermöglichen?
Seht ihr da irgendwelche Probleme oder kann das alles so funktionieren?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 05 Dezember 2018, 21:08:00
Zitat von: matthias soll am 05 Dezember 2018, 20:50:39
ich habe mal eine Frage zu den Seriellen schnittstellen vom MapleCUN.
Funktionieren die auch mit dem 5500 ethernet shield?
Im Wiki steht über usb werden die bereitgestellt nicht auch über lan?
Das habe ich geschrieben und gerade nochmals gelesen und verstehe den Text selber so, dass das auch per LAN geht, was das Beispiel mit der IP:Port ja auch belegt. Wenn du einen besseren Vorschlag zum Text hast: Bitte hier oder direkt im Wiki schreiben.



ZitatUnd kann ich an eine serielle schnittstelle eine Infrarotdiode mit treibertransistor hängen und mit LIRC ansteuern?
Du kannst übers Netz Daten mit festgelegter Geschwindigkeit ausgeben. Wie man LIRC dazu bringt die Daten zu der IP/Port zu senden weisst du bestimmt besser als ich. :o


ZitatUnd an die andere einen CC2530 um zigbee zu ermöglichen?
Kannst Du. Falls es bequem sein soll, ggf. so: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/AddOns/RasPi-UART__Zigbee-CC2530/top-v02.png

Hier gibt es auch Infos: https://wiki.fhem.de/wiki/MapleCUX-Platinen#Zus.C3.A4tzliche_Serielle_Schnittstellen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 06 Dezember 2018, 05:28:26
perfekt danke für die ausführliche Antwort.
Dann werde ich mich daran mal versuchen.

wegen der seriellen hatte mich der Satz irritiert "Über USB werden zwei weitere Schnittstellen angelegt"
deswegen hatte ich gedacht weil explizit auf USB hingewiesen wird, dass das bei LAN nicht geht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 06 Dezember 2018, 08:04:54
Besser verständlich ? https://wiki.fhem.de/wiki/MapleCUN#Zus.C3.A4tzliche_Serielle_Schnittstellen
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 06 Dezember 2018, 09:03:04
Hi,
Ja, aber kann man einen Code Schnipsel machen für die Baudraten?

Die setzt man doch über einen set Maple raw pb0@9600 oder?

Also etwa so:

Die UARTs werden als "virtuelle" Schnittstellen per USB und LAN bereitgestellt:

Über USB werden zwei weitere Schnittstellen angelegt. (Typischerweise neben /dev/ttyACM0 eben /dev/ttyACM1 und /dev/ttyACM2 unter Linux und unter Windows einfach zwei weitere COM Ports.)

Der Netzwerkzugriff auf die UARTS erfolgt analog über zwei weitere Ports: 2324 und 2325.

Zur Einstellung der Baudrate über Netzwerk gibt es folgende Befehle:

UART0 Baudrate einstellen: pb0@38400
UART1 Baudrate einstellen: pb1@9600
Baudrate im EEPROM speichern: ps
Baudrate anzeigen: pi


set MapleCUL raw pb0@38400
set MapleCUL raw pb1@9600
set MapleCUL raw ps
get MapleCUL raw pi


Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 08 Dezember 2018, 13:51:59
Hallo zusammen,

wie definiere ich die UART´s denn richtig?
Das einzige Beispiel was ich finden konnte war:

define myRemoteHmUART HMUARTLGW uart://192.168.42.23:2324

Wenn ich den Maple direkt am USB habe ist das dann richtig?

define MapleUART UART uart0:2324

Gruß
Matthias
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 08 Dezember 2018, 14:58:06
Hi,
Nein direkt am USB hast du ja drei USB Ports. Unter Linux z.B. /dev/ttyACM0 bis /dev/ttyAMC2
Ich habe gestern ein HM UART an die zweite Serielle auf einer Ranseyer Platine gelötet und local ,,by-id" angesprochen:

define mapleCUL CUL /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00@38400 4444
define myRemoteHmUART HMUARTLGW /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if02
(http://define%20maplecul%20cul%20/dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00@38400%204444%3Cbr%20/%3Edefine%20myRemoteHmUART%20HMUARTLGW%20/dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if02)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 09 Dezember 2018, 08:02:41
Ach so ok das hilft mir weiter.
Sehr gut auch gleich im WIKI eingetragen.
Ich biete mich gerne als WIKI Tester DAU (dümmeter anzunehmender user) an. ;D
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 Dezember 2018, 09:39:04
Zitat von: RaspiLED am 06 Dezember 2018, 09:03:04
Also etwa so:


Danke hab ich übernommen (was noch fehlte).
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 10 Dezember 2018, 14:47:30
Was passiert eigentlich, wenn ich zwei Funkmodule verbaue, die die gleichen Signale empfangen? Also die Daten doppelt in FHEM ankommen? Nur mal so rein interessehalber... wird sowas irgendwie abgefangen? Oder sollte man das einfach nicht machen  ;D
Würde ja befürchten, dass dann Trigger o.ä. in FHEM doppelt ausgelöst werden
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 10 Dezember 2018, 14:51:02
Das mit "doppelten IOs" ist in der Praxis nach meiner bisherigen Erfahrung kein Problem, hängt aber ggf. auch an den jeweiligen Modulen.

Kann nur für HM und den mit CUL433 bzw. SignalDUINO reinkommenden Messages sprechen, aber da wird in der Regel nur das erste "gleiche" Funksignal (für eine kurze Dauer) verarbeitet, der Rest wird weggeworfen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 11 Dezember 2018, 21:18:11
Eine Frage, ich habe einen 4x MapleCUN mit folgender Version:
ZitatV 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_8F (F-Band: 868MHz)

Ist es möglich über die USB Schnittstelle oder OTA ein Update durchzuführen, oder muss ich das immer über einen USB/TTL Adapter machen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 11 Dezember 2018, 21:29:09
ZitatIst es möglich über die USB Schnittstelle oder OTA ein Update durchzuführen,
Das kommt darauf an ob Dein Gerät einen USB-Bootloader hat. Laut der Doku vom Telekatz soll man schon lange so flashen.
(Die Module von mir sind alle so geflasht)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 11 Dezember 2018, 22:06:55
Habe ihn damals bei dir gekauft :) Ok, dann muss ich jetzt nur noch durchsteigen, wie das geht. Dank Dir.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 12 Dezember 2018, 11:52:40
Suche doch mal im Wiki nach MAPLE. Da solltest du zwei Treffer bekommen...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 12 Dezember 2018, 11:58:21
Zitat von: Amenophis86 am 11 Dezember 2018, 22:06:55
Habe ihn damals bei dir gekauft :) Ok, dann muss ich jetzt nur noch durchsteigen, wie das geht. Dank Dir.

Ist doch alles schön beschrieben im Wiki.

Beispiel für Windows 7: https://wiki.fhem.de/wiki/MapleCUN#Firmware_flashen_unter_Windows_7_-_64bit (https://wiki.fhem.de/wiki/MapleCUN#Firmware_flashen_unter_Windows_7_-_64bit)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 13 Dezember 2018, 00:09:26
Lässt sich drüber streiten. Zum einen war nicht klar, wo das Programm für Windows her kommt zum zweiten, was da nun ein Befehl ist und was automatisch Ausgabe des Programms. Aber werde es mir die Tage anschauen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 13 Dezember 2018, 21:10:22
Habe den Maple per USB an meinem Win10 PC angeschlossen. Es blinkt die blaue LED ca. alle 2 sekunden. Wenn ich jetzt den einen Knopf drücke, dann blinkt sehr schnell blau, dann etwas langsamer blau und dann wieder alle 2 sek blau. Ich kann so oft ich will den anderen Knopf drücken bei der Eingabe in die Commandzeile kommt immer wieder:

D:\FHEM Server\Download\dfu-util-0.9-win64>dfu-util --list
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/


Jemand ne Ahnung was ich falsch mache? Habe auch mal erst den anderen Knopf gedrückt, da passiert gar nix.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 13 Dezember 2018, 21:13:53
Hast du das gemacht:

Reset des Maple durch drücken des Reset Buttons
Drücken des "but=32" Buttons direkt nach dem Reset
Der Maple sollte jetzt im 4 Hz Takt blinken

Manchmal hilft es auch wenn man den but=32 Button mehrfach schnell nach dem Reset drückt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 13 Dezember 2018, 21:15:43
Wie gesagt, ich habe zwei Knöpfe welche ich drücken kann. Leider kann ich nicht die Beschriftung sehen da die Platine im Gehäuse mittels Heißkleber fixiert wurde. Aber genau das passiert, wenn ich was drücke:

Zitat von: Amenophis86 am 13 Dezember 2018, 21:10:22
Es blinkt die blaue LED ca. alle 2 sekunden.
Wenn ich jetzt den einen Knopf drücke, dann blinkt sehr schnell blau, dann etwas langsamer blau und dann wieder alle 2 sek blau.

Ich kann so oft ich will den anderen Knopf drücken bei der Eingabe in die Commandzeile kommt immer wieder:

Auch mehrfaches schnell Drücken des anderen Knopfes ändert nichts.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 13 Dezember 2018, 21:16:43
Zeig doch bitte mal ein Bild.

Du musst den 2. Knopf mehrfach kurz nach dem reset drücken
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 13 Dezember 2018, 21:19:40
Hatte ich gerade vor :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 13 Dezember 2018, 21:20:58
Beim klicken auf den oberen Knopf zwischen den Kontakten verändert er das blink Verhalten, beim unteren passiert nix. Drücke erst den oberen und dann mehrfach den unteren. Am Ende blinkt er aber immer wieder wie zu Beginn ca. alle 2 Sekunden und das Programm scheint ihn nicht zu finden oder zu erkennen.

Müsste ich den Maple im Gerätemanager irgendwo sehen? Finde ihn dort nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 13 Dezember 2018, 21:21:53
Der obere ist der Reset.

Manchmal klappt es bei mir auch erst beim 5-10 Versuch. Einfach dran bleiben.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 13 Dezember 2018, 21:27:40
Ok nach gefühlten 100 Versuchen blinkt er nun schnell, aber es bleibt dabei, dass das Programm ihn wohl nicht findet. Immer die gleiche Meldung, wie oben geschrieben.

Edit:
Ok ernst gemeinte Frage:
Ranseyer du hast gesagt, dass du schon den anderen Bootloader drauf gemacht hast, dann müsste ich doch auch einfach die neue Firmware über USB flaschen können, oder muss ich trotzdem einen TTL/USB nutzen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 13 Dezember 2018, 22:54:33
Hi, wenn der nicht im Gerätemanager ist, dann hast Du
A) ein Nur Stromkabel (bitte tauschen) oder
B) nicht die richtigen Treiber
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Maple-drivers

Gruß Arnd

P.S.: Den Bootloader kann man doch auch über USB umprogrammieren:
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Amenophis86 am 14 Dezember 2018, 06:09:17
Als er dann im Flashmodus war hat der PC ihn auch im Gerätemanager gehabt. Muss schauen, wann ich wieder Zeit habe es zu versuchen. Gestern habe ich dann abgebrochen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 14 Dezember 2018, 06:36:03
Siehst du denn in Zadig ein device wo du den Treiber neu setzen kannst?

https://zadig.akeo.ie
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 14 Dezember 2018, 11:34:56
Weil mir das zu blöd ist flashe ich nur unter Linux mit dem Script: https://wiki.fhem.de/wiki/MapleCUN#Firmware_.2F_Flashen.
Da muss man nur solange die Tools installieren oder kompilieren bis diese gefunden werden und dann den Text lesen...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 18 Dezember 2018, 06:52:13
Hallo zusammen,
ich frickel nun seit 2 Wochen und komme nicht weiter.
Ich versuche LIRC auf einen der Maplecun UART´s zu benutzen.
ALLE anleitungen für den Raspberry benutzen die GPIO´s vom Raspberry.
Es gibt das Modul lirc_rpi was in raspbian integriert ist,
das ist scheinbar ein umbebasteltes serielles modul und ich konnte das bisher nicht dazu bewegen auf meine ttyACM1 zuzugreifen.
Vielleicht kann mir hier jemand weiterhelfen?
Gruß
Matthias
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 18 Dezember 2018, 20:07:18
Hallo Zusammen,
Beim Maplemini gibt's es ja diverse Unterschiede.
Kann man da auch einen STM32F103CBT6 holen oder ist da was zu beachten?

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Dezember 2018, 20:41:42
Zitat von: matthias soll am 18 Dezember 2018, 06:52:13
Hallo zusammen,
ich frickel nun seit 2 Wochen und komme nicht weiter.
Ich versuche LIRC auf einen der Maplecun UART´s zu benutzen.
ALLE anleitungen für den Raspberry benutzen die GPIO´s vom Raspberry.
Es gibt das Modul lirc_rpi was in raspbian integriert ist,
das ist scheinbar ein umbebasteltes serielles modul und ich konnte das bisher nicht dazu bewegen auf meine ttyACM1 zuzugreifen.
Vielleicht kann mir hier jemand weiterhelfen?
Gruß
Matthias
Was soll das für ein Interface sein, dass du an den MapleCUN anschließen möchtest? Die einfachen LIRC Interface für den Seriellen Port funktionieren über einen USB Wandler sowieso nicht.

Zitat von: Markus. am 18 Dezember 2018, 20:07:18
Hallo Zusammen,
Beim Maplemini gibt's es ja diverse Unterschiede.
Kann man da auch einen STM32F103CBT6 holen oder ist da was zu beachten?
Eigentlich gibt es da keine Unterschiede. Auf einem Maple Mini ist immer ein STM32F103CBT6 verbaut.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: blueicechip am 18 Dezember 2018, 21:04:29
LIRC hat ja auch nichts mit seriellen Schnittstellen oder UARTs zu tun - am PC wurden die nur als I/O Pins missbrauchten.

am Maple könnte man einen Arduino/Atmel davor schalten, der das IR Signal auswertet oder ein Modul für den Maple schreiben, das die Decodierung über nimmt - oder gleich n fertiges ESP Projekt benutzen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 18 Dezember 2018, 21:26:08
Danke für das Feedback.
Es gibt aber ein lirc_serial oder neu ein serial_ir Modul was die verbindung schaffen soll.
Und das lirc_rpi Modul was verwendet wird soll auch nur ein umgefrickeltes lirc_serial sein.
Leider habe ich nicht genug LINUX Erfahrung um Module einzubauen oder ähnliches.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Dezember 2018, 21:33:33
Und nochmal die Frage: Was soll das für ein Interface sein, dass du an den MapleCUN anschließen möchtest?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 18 Dezember 2018, 21:45:42
Oh sorry hatte deine Frage übersehen.
ich hatte an das hier beschriebene gedacht: https://www.huitsing.nl/irftdi/
Und den habe ich unter windows an einem ftdi USB wandler funktionsfähig laufen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 18 Dezember 2018, 22:19:36
Das funktioniert nur mit einem FTDI Wandler. An jedem anderen USB Wandler, also auch am MapleCUN, funktioniert das so nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 18 Dezember 2018, 22:24:19
OK schade, danke für die Info.
Dann brauche ich das nciht weiter probieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 19 Dezember 2018, 12:59:15
Naja, erledigt ist das ganze evtl. nicht. du kannst an einen der UARTs hängen was du willst. Arduino oder nochmals ein Maple, und der kann dann machen was du möchtest...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 19 Dezember 2018, 16:35:19
Da hast du absolut recht ich probiere grade
https://github.com/z3t0/Arduino-IRremote/commits/master
Dann flansche ich noch einen arduino dazwischen und spreche mit dem über die UART.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 19 Dezember 2018, 16:45:57
//OT:
Ich würde sicherlich noch Teile dazu finden: http://www.neuby.de/wp/ir-empfaenger-basiert-auf-v-usb/ (Die Teile habe ich schon ewig nicht mehr gebaut)
Oder das ganze auch für nen STM32 Programmer oder Maple. Falls ich noch nen ST-Link V2 finde kannst du den gerne kostenlos haben.

Willst Du eigentlich IR senden oder empfangen ?


PS: Lass und das Thema zumindest innerhalb des Threads von Telekatz beenden weil OT !
Ende OT//
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: nonamenogame am 20 Dezember 2018, 23:28:33
Hallo Zusammen,

ich hatte vor kurzem auch nen MAPLECUL von Ranseier erworben, der tut es soweit ganz gut.

Allerdings habe ich nun ne kleine Herausforderung was MAX! angeht.

Hintergrund ist der, dass ich diese Fenster Sensoren besorgt hatte. Nun hatte ich irgendwo gelesen, das nur der letzte stackable CUL MAX! können soll.

Stelle ich ihn im rf mode auf MAX, macht er das auch fröhlich, allerdings fehlt mir da die Möglichkeit ihn in den pairingmode zu versetzen.

Leider habe ich wenig bis gar kein Plan von MAX! und das wiki gibt aus meiner Sicht auch nichts brauchbares für MAPLECUL<->MAX her.

Mir ist vollkommen klar, dass das Problem sehr wahrscheinlich gerade an der Tastatur sitzt, jedoch wäre ich euch dankbar, wenn ihr mir nen Schubs in die richtige Richtung geben könntet.

Beste Grüße
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 20 Dezember 2018, 23:31:29
Kenne jetzt max nicht, aber m.E. kannst du jeden Stack behandeln wie einen normalen CUL. Will heißen: Du suchst an der m.E. falschen Stelle, müßte ganz allg. bei CUL stehen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: nonamenogame am 21 Dezember 2018, 03:06:53
Ok, danke für die Hinweise, nach ein wenig weitersuchen, hat es dann endlich geklappt;-)

https://forum.fhem.de/index.php?topic=78718.msg874692#msg874692
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: moerte am 21 Dezember 2018, 17:02:10
Hallo meine lieben -
hab seit heute auch einen mapleCUL in Betrieb über LAN - einrichtung ging ohne Probleme nach FhemWiki -

define mapleCUN1 CUL 192.168.2.20:2323 1111

und
define mapleCUN2 STACKABLE_CC mapleCUN1

jetzt hab ich schon so viel probiert und bekomm einfach keinen Schaltvorgang hin -
wenn ich z.B. meine Steckdosen schalten möchte geht leider gar nichts.

Das Log sieht gut aus dabei.
Die Frequenz ist auf 433.920 (wie auch die Steckdosen 433.92)

hier ein list vom mapleCUN1:

Internals:
   CFGFN     
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        192.168.2.20:2323 1111
   DeviceName 192.168.2.20:2323
   FD         47
   FHTID      1111
   NAME       mapleCUN1
   NR         23406
   PARTIAL   
   RAWMSG     *isFF000F0FFFF0
   STACKED    mapleCUN2
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_8F (F-Band: 868MHz)
   initString X21
   mapleCUN1_MSGCNT 6
   mapleCUN1_TIME 2018-12-21 16:54:48
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-12-21 16:36:19   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2018-12-21 16:54:48   state           Initialized
Attributes:
   room       System



hier ein list vom mapleCUN2:

Internals:
   CFGFN     
   CMDS       bCFiAZNEGMKLUYRTVWXfz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        mapleCUN1
   IODev      mapleCUN1
   NAME       mapleCUN2
   NOTIFYDEV  mapleCUN1
   NR         23421
   NTFY_ORDER 50-mapleCUN2
   PARTIAL   
   RAWMSG     isFF000F0FFFF0
   STACKED    mapleCUN3
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_8F (F-Band: 433MHz)
   initString X21
   mapleCUN2_MSGCNT 6
   mapleCUN2_TIME 2018-12-21 16:54:48
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-12-21 16:36:42   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-12-21 17:02:45   cmds             b C F i A Z N E G M K L U Y R T V W X f z *
     2018-12-21 17:07:45   raw             is0FF00F0FFFF0
     2018-12-21 17:02:45   state           Initialized
Attributes:
   rfmode     SlowRF
   room       System


Könnte mir evtl jemand sagen was ich übersehen habe einzustellen oder hab ich Grundlegend etwas falsch gemacht?
Die angelegten Steckdosen habe ich das IODev mapleCUN2 gegeben.


Edit: OK das logfile sieht doch nicht OK aus??

2018.12.21 17:32:04 3: mapleCUN2 IT_set: Bogen_WZ_rechts on
2018.12.21 17:32:07 2: IT IODev device didn't answer is command correctly:   raw => No answer
2018.12.21 17:32:07 3: mapleCUN2 IT_set: Bogen_WZ_rechts on
2018.12.21 17:32:10 2: IT IODev device didn't answer is command correctly:   raw => No answer
2018.12.21 17:32:19 3: mapleCUN2 IT: message "isff000f0fff0f" (14) too short!
2018.12.21 17:32:19 3: mapleCUN2 IT: message "isff000f0fff0f" (14) too short!
2018.12.21 17:32:19 3: mapleCUN2: Unknown code isff000f0fff0f, help me!
2018.12.21 17:32:20 3: mapleCUN2 IT: message "isff000f0fff0f" (14) too short!
2018.12.21 17:32:20 3: mapleCUN2 IT: message "isff000f0fff0f" (14) too short!
2018.12.21 17:32:20 3: mapleCUN2: Unknown code isff000f0fff0f, help me!



Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: moerte am 21 Dezember 2018, 18:46:33
Ich nehm mal wieder alles zurück .. keine Ahnung lag wohl an der Antenne. Habe meine alte genommen damit ging es auf einmal.
Super Sache. Trotzdem danke an die sich jetzt Gedanken gemacht haben..
LG und ein tolles Wochenende
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Dergemer am 30 Dezember 2018, 22:42:29
Hi, sorry wenn ich hier grad so reinschneie, die Suche hat leider nichts ergeben, was mir weiterhilft (was nicht heißt, dass es nichts gibt ;-) )

Ich habe einen FIBARO DIMMER2 (FGD-212) und ein 4fach MAPLE-CUL.

Kann ich die beiden irgendwie (relativ einfach) miteinander kommunizieren lassen?

das wiki (https://wiki.fhem.de/wiki/MapleCUN (https://wiki.fhem.de/wiki/MapleCUN)) hilft mir leider nicht wirklich weiter... :-/


Für Homematic habe ich das jetzt geschafft. Das sieht so aus:

defmod MAPLECUL868HM CUL FHEM:DEVIO:MAPLECUL433Stack:9600 0000
attr MAPLECUL868HM group Gateways
attr MAPLECUL868HM hmId 737373
attr MAPLECUL868HM icon cul_868
attr MAPLECUL868HM rfmode HomeMatic


setstate MAPLECUL868HM 2018-12-29 13:22:29 cmds  b C A Z N E L Y V X f z *
setstate MAPLECUL868HM 2018-12-29 14:40:40 state Initialized
setstate MAPLECUL868HM 2018-12-29 14:11:16 version V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_8F (F-Band: 868MHz)


defmod MAPLECUL868 CUL 192.168.178.4:2323 0703
attr MAPLECUL868 group Gateways
attr MAPLECUL868 icon cul_868
attr MAPLECUL868 model CUN
attr MAPLECUL868 rfmode SlowRF


setstate MAPLECUL868 2018-12-29 13:22:29 cmds  B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
setstate MAPLECUL868 2018-12-29 14:42:13 state Initialized
setstate MAPLECUL868 2018-12-29 14:11:45 version V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_8F (F-Band: 868MHz)



oder bin ich hier irgendwie komplett falsch?

würde mich über eine Antwort freuen.
VG, Jens
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 31 Dezember 2018, 06:40:29
Hi,
kurze Recherche hier im Forum sagt:
https://forum.fhem.de/index.php?topic=77271.msg692190#msg692190

Also ist Dein Fibaro ein ZWave Gerät. Es gab erste Ansätze die drei unterschiedlichen ZWave Geschwindigkeiten mittels dreier CC1101 auf MapleCUL zu bedienen, da ist es aber ruhiger drum geworden:
https://forum.fhem.de/index.php/topic,68811.msg614897.html#msg614897

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pejonp am 31 Dezember 2018, 11:36:26
Hallo Dergemer,

ich habe einen MAX!_Cube auf 3x CC1101 umgebaut. Definition sollte aber bei allen CULs gleich sein. Vielleicht Anfrage nach ZWAVE verschieben oder STACKABLE CUL.
Version: V 1.26.03 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
Damit empfange ich auf 868MHz (ggf. umschalten, da ein CC1101 auf 433MHz)

CUL_1: MAX!

defmod CUL_1 CUL 192.168.x.xxx:2323 3034
attr CUL_1 model CUN
attr CUL_1 rfmode MAX
attr CUL_1 room TRX


CUL_2: Homematic und

define CUL_1_SCC STACKABLE CUL_1
attr CUL_1_SCC room TRX
define CUL_2 CUL FHEM:DEVIO:CUL_1_SCC:9600 0000
attr CUL_2 hmId 424242
attr CUL_2 model CUN
attr CUL_2 rfmode HomeMatic
attr CUL_2 room TRX


CUL_3: ZWAVE

define CUL_2_SCC STACKABLE CUL_2
attr CUL_2_SCC room TRX
define CUL_3 ZWCUL FHEM:DEVIO:CUL_2_SCC:9600 017b37f1 01
attr CUL_3 intruderMode 1
attr CUL_3 room TRX,ZWave
attr CUL_3 verbose 1



pejonp
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 31 Dezember 2018, 17:59:36
Da ich noch im Aufbau bin (Teilelieferung dauert leider ewig), kann ich es noch nicht selbst prüfen, aber hier ist ein Link zu einer funktionalen Konfiguration von A.Harrenberg:

https://forum.fhem.de/index.php/topic,60458.msg653276.html#msg653276 (https://forum.fhem.de/index.php/topic,60458.msg653276.html#msg653276)

Edit: Gerade gesehen, dass Arnd / RaspiLED das auch schon verlinkt hatte - sorry!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Januar 2019, 13:10:41
Hallo,

Ich habe ein neues Gehäuse für den MapleCUN/CUL in der Version 3.4 erstellt. Vielleicht hat jemand Interesse daran:

https://www.thingiverse.com/thing:3332836
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 04 Januar 2019, 13:20:26
Klasse, sieht super aus. Suche mir auch gerade ein Gehäuse (hab keinen 3D-Drucker).

Mal eine Frage:
Euro-Format ist: 100 mm x 160 mm (https://de.wikipedia.org/wiki/Europakarte)

Halbes Euro-Format ist doch 100 mm x 80 mm, oder?
(https://www.elektronikentwickler-aachen.de/layouterstellung/layouterstellung_22.htm)

Das komische ist, dass die Maple-Platine doch 100 mm x 60 mm hat.

Das Kemo-Gehäuse G088 ist laut eigenen Angaben für halbes Euro-Format gedacht und aber bietet auch nur 60 mm:
http://downloads.cdn.re-in.de/525000-549999/530878-da-01-de-UNIVERSALGEHAEUSE_G088_120X70X15MM.pdf

Also ist halbes Euro-Format 100x60 oder 100x80? Oder ist man sich noch nicht so sicher?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 Januar 2019, 13:39:10
Zitat von: gloob am 04 Januar 2019, 13:10:41
Ich habe ein neues Gehäuse für den MapleCUN/CUL in der Version 3.4 erstellt. Vielleicht hat jemand Interesse daran:
https://www.thingiverse.com/thing:3332836

Mist, nun muss ich meinen Drucker von den Maples und anderes Teilen freiräumen die in letzter Zeit gekommen sind um sofort das Teil zu drucken. Denn genau so stelle ich mir das äußere vor!
Ich würde mich nochmals melden wegen höherer Deckel-Version wenn "Mann" AddOns darauf steckt...

=> Danke für den Einsatz !


ZitatHalbes Euro-Format ist doch 100 mm x 80 mm, oder?
So würde ich das sehen! Die Maple Platine ist aber mehr auf gute ausnutzung des Platinenmaterials ausgelegt. Und wenn man diese im Kemo Gehäuse verschrauben will dürfte diese auch noch schmaler sein.
Ist aber kein halbes Euro-Format !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 04 Januar 2019, 13:42:30
Zitat von: Ranseyer am 04 Januar 2019, 13:39:10
So würde ich das sehen! Die Maple Platine ist aber mehr auf gute ausnutzung des Platinenmaterials ausgelegt. Und wenn man diese im Kemo Gehäuse verschrauben will dürfte diese auch noch schmaler sein.
Ist aber kein halbes Euro-Format !
Aber aber... Des Kemo Gehäuse wird beschrieben mit "Wandgehäuse mit Befestigungslaschen zum Einbau von Platinen im halben Euro-Format. " und ist aber insgesamt nur 70 mm breit. Irgendwas versteh ich da nicht. Oder ich sollte Freitags nix mit Zahlen machen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Januar 2019, 13:46:37
Zitat von: vbs am 04 Januar 2019, 13:42:30
Aber aber... Des Kemo Gehäuse wird beschrieben mit "Wandgehäuse mit Befestigungslaschen zum Einbau von Platinen im halben Euro-Format. " und ist aber insgesamt nur 70 mm breit. Irgendwas versteh ich da nicht. Oder ich sollte Freitags nix mit Zahlen machen.

Die Platine von der V3.4 ist 59x100mm groß.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 Januar 2019, 13:50:45
Zitat von: vbs am 04 Januar 2019, 13:42:30
Aber aber... Des Kemo Gehäuse wird beschrieben mit "Wandgehäuse mit Befestigungslaschen zum Einbau von Platinen im halben Euro-Format. " und ist aber insgesamt nur 70 mm breit.

Ahh, das hab ich nicht gesehen. Die Kemo Gehäuse sind laut Lineal etwas unter 70mm. Somit bin ich bei dir.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Januar 2019, 14:07:09
Zitat von: Ranseyer am 04 Januar 2019, 13:39:10
Ich würde mich nochmals melden wegen höherer Deckel-Version wenn "Mann" AddOns darauf steckt...

Wieviel höher brauchst du es denn? Aktuell sind zwischen Platinen und Deckel 18.5mm Platz.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 04 Januar 2019, 15:21:27
Sieht gut aus gloob - danke.

ZitatDie Platine von der V3.4 ist 59x100mm groß.

Das sollte eigentlich doch auch mit der 3.3 Large passen. 100.02 mm x 59.8 mm - von den Aus- und Eingängen sollte es doch auch stimmig sein.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Januar 2019, 15:25:33
Zitat von: dmq am 04 Januar 2019, 15:21:27
Sieht gut aus gloob - danke.

Das sollte eigentlich doch auch mit der 3.3 Large passen. 100.02 mm x 59.8 mm - von den Aus- und Eingängen sollte es doch auch stimmig sein.

Ist die Platine wirklich 59,8mm breit? Die 3.4 hat eine Breite von 59mm und so habe ich auch das Gehäuse erstellt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 04 Januar 2019, 15:47:11
ZitatIst die Platine wirklich 59,8mm breit?

Ich habe gerade noch mal gemessen: 59.95 mm sogar  :-\

Das Gehäuse von Eistee passt leider auch mehr schlecht als recht. Habe da Potenzial etwas zu zerstören. Ich denke dann muss ich eines der Designs wohl anpassen. Hast Du das in Fusion gemacht?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Januar 2019, 15:48:12
Zitat von: dmq am 04 Januar 2019, 15:47:11
Ich habe gerade noch mal gemessen: 59.95 mm sogar  :-\

Dann wird das Gehäuse leider nicht passen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 04 Januar 2019, 15:52:04
Habe gerade meinen Post noch mal angepasst - falls Du es nicht sehen solltest: hast Du das Design in Fusion gemacht und würdest Du es ggf. auch teilen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 Januar 2019, 17:31:09
So sieht das bei mir aus (PETG mit leicht kaputtem Druckkopf).

Zu der Breite meiner Platinen. Laut CAD Daten sind diese etwas schmäler als manchmal in der Praxis. Denke es wäre besser in der Breite noch mindestens 2mm extra zu spendieren.
(Vollständig wäre ja die Antennenseite, ich habe nur auf der Gegenseite am Material gespart.)

Zur Höhe: Schwierig... Ich schiesse gleich mal ein paar Fotos.
Evtl sollten wir das Thema in einem anderen Thread weiter diskutieren ? (Mit dem Maple-CUL an sich hat das ja wenig zu tun)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 Januar 2019, 17:46:07
Denke der Worst-Case sind 42mm ab der Oberkante deiner Bodenschale bis zur Oberkante der SMA Buchse vom CC2530.

Nur das untere AddOn dürften max. 20 mm sein.

edit: Und der die USB-Buchse des Maple unter der Platine passt haarscharf ins Gehäuse rein...

edit2: Und was auch noch passieren könnte: eine dritte flache Platine um eine WLAN Anbindung stecken zu können. (Aber irgendwann mal ist auch mal Schluss und es empfiehlt sich das größte von KEMO oder so...)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 05 Januar 2019, 08:00:48
@dkreutz

Hi Dominik,

Sag mal hast Du das Problem mit den "unknown Codes" bei dem Lacrosse Devices auf mCUL0 eigentlich in den Griff bekommen?
Zitat

define mCUL0_LaCrosse CUL 192.168.1.53:2323 1234
attr mCUL0_LaCrosse connectCommand Nr1
attr mCUL0_LaCrosse model CUN
attr mCUL0_LaCrosse rfmode SlowRF

CUL0:





UNKNOWNCODE N01EFA23E3F273166A5AAAAAA00


funktioniert soweit gut, empfängt sogar Sensoren aus der Nachbarschaft. Es gibt aber immer wieder Eventlog-Meldung folgender Art



Habe im Moment das gleiche Poblem...


2019-01-05 07:49:07 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000119DE4
2019-01-05 07:49:15 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000029445
2019-01-05 07:49:23 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000240418
2019-01-05 07:49:31 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000027B880
2019-01-05 07:49:39 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000232382
2019-01-05 07:49:48 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00003438C1
2019-01-05 07:49:56 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000010F02B
2019-01-05 07:50:04 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00000A8789
2019-01-05 07:50:12 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00000D1809
2019-01-05 07:50:20 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000047316
2019-01-05 07:50:28 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000201022
2019-01-05 07:50:37 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000320443
2019-01-05 07:50:45 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000092418
2019-01-05 07:50:53 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00000859B2
2019-01-05 07:51:01 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00001330F5
2019-01-05 07:51:09 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000008000
2019-01-05 07:51:17 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00000215E5
2019-01-05 07:51:25 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000316224
2019-01-05 07:51:34 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000024048
2019-01-05 07:51:42 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000000490
2019-01-05 07:51:50 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000024401E
2019-01-05 07:51:58 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000063500
2019-01-05 07:52:06 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000010642E
2019-01-05 07:52:14 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000111B10
2019-01-05 07:52:23 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00001DCA30
2019-01-05 07:52:31 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000213641
2019-01-05 07:52:39 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000160A86
2019-01-05 07:52:47 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000103625
2019-01-05 07:52:55 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000003200
2019-01-05 07:53:03 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00001A110C
2019-01-05 07:53:11 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000021C26
2019-01-05 07:53:20 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000052081
2019-01-05 07:53:28 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000242824
2019-01-05 07:53:36 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000008D40B
2019-01-05 07:53:44 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000281E81
2019-01-05 07:53:52 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000000C2E4
2019-01-05 07:54:00 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000008E5E7
2019-01-05 07:54:09 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000035A31
2019-01-05 07:54:17 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000036E600
2019-01-05 07:54:25 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000000824B
2019-01-05 07:54:33 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00002A0F08
2019-01-05 07:54:41 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000004D4C
2019-01-05 07:54:49 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000080820
2019-01-05 07:54:58 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000023D940
2019-01-05 07:55:06 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000007D041
2019-01-05 07:55:14 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00002491E8
2019-01-05 07:55:22 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00002B10A7
2019-01-05 07:55:30 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000081852
2019-01-05 07:55:38 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000010B344
2019-01-05 07:55:46 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000002409
2019-01-05 07:55:55 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00001CA811
2019-01-05 07:56:03 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00000C88EA
2019-01-05 07:56:11 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00000DC03B
2019-01-05 07:56:19 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000006100
2019-01-05 07:56:27 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000020460D
2019-01-05 07:56:35 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00003C5601
2019-01-05 07:56:44 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000000C003
2019-01-05 07:56:52 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000017C805
2019-01-05 07:57:00 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000248894
2019-01-05 07:57:08 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000255390
2019-01-05 07:57:16 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00002CA008
2019-01-05 07:57:24 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000008135
2019-01-05 07:57:32 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000278996
2019-01-05 07:57:41 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000381411
2019-01-05 07:57:49 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000345805
2019-01-05 07:57:57 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA000010D028
2019-01-05 07:58:05 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000105260
2019-01-05 07:58:13 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000304781
2019-01-05 07:58:21 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00003CB279
2019-01-05 07:58:30 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA00000304B9
2019-01-05 07:58:38 CUL mCUL0_LaCrosse UNKNOWNCODE N019285602CDAAAAA0000180406


Irgendeiner eine Idee wie man das in den Griff bekommt?

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dkreutz am 05 Januar 2019, 09:52:16
Zitat von: Markus. am 05 Januar 2019, 08:00:48
@dkreutz

Hi Dominik,

Sag mal hast Du das Problem mit den "unknown Codes" bei dem Lacrosse Devices auf mCUL0 eigentlich in den Griff bekommen?
Habe im Moment das gleiche Poblem...


Ja und nein. Im CUL Device habe ich verbose=2 eingestellt, dadurch wird das Log nicht damit zugemüllt.
Im Eventlog tauchen die Meldungen weiterhin auf :(
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 05 Januar 2019, 16:33:31
für IT bekomme ich auch folgende Einträge...


2019.01.05 16:29:19 3: mCUL1_IT IT: Code 1010 not supported by IT_1527xc5ffb.


Gruß

Markus

Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 05 Januar 2019, 20:32:09
Hi, dann definiere die 1010 doch. Ist es der on, off, dim-up oder Dom-down Code???
Siehe Commandref des Define des IT Devices...

define myITSwitch IT <housecode>< group_switch> <on-code> <off-code> [<dimup- code> <dimdown-code>]

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 06 Januar 2019, 09:34:45
mmh... Hab festgestellt, das dieses Ding eins von meinen Nachbarn irgendwo ist... ;D ;D ;D
Also kann ich dieses Problem mal bei die Akten legen und das device auf ignore setzten ;-)


Hab aber noch eine Frage zu den Addon Boards...

Will mein MySensors RFM69 Serial Gateway mit dem Maple ablösen. Der Maple ist wie folgt bestückt
3x868 (Lacrosse,Homeatic (zum spielen), Max)
1x433 (IT)
Dann hab ich noch einen HM-UART drauf der ja auf UART0 läuft. Bei dem Addon-Board, was ich als Mysensors-RFM69 Gateway aufgebaut habe blicke ich im Moment nicht durch wie ich den "Jumper" das er auf UART1 läuft.
Für RX und TX sind ja zwei Lötbrücken drauf. Wenn ich das richtig verstehe sind die "by Default" so eingestellt, das sie auf UART0 laufen.

Wäre klasse wenn mi da mal einer auf die Sprünge helfen könnte.

Viele Grüße

Markus


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 06 Januar 2019, 11:25:19
@Markus: Du nimmst
-den Schaltplan der Hauptplatine: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Archiv/V3.4/Schematic.png (und siehst das Homematic am UART1 ist)
-den Schaltplan des AddOns: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/AddOns/RFM69-usw-aktuell/schematic.png (da suchst du den Weg vom Arduino bis zum UART0)

Also wenn ich jetzt nicht total daneben gesehn habe: Keine Jumper ändern. Das war ja die Idee, Homematic-Modul und eine andere Sache möglichst ohne Jumper zu ändern...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 06 Januar 2019, 22:20:41

Sagt mal, beim HM-MOD-UART, ich hab gemerkt, dass ich Probleme mit den Timings von virtuellen Sensoren hab und frank hat mich mal auf die roundtrip-Ausgaben aufmerksam gemacht. Der Maple ist bei mir per USB angebunden und die RoundTripTimes sehen so aus:
2019.01.06 21:35:18.411 0: HMUARTLGW sys_culHm roundtrip delay: 0.1397
2019.01.06 21:35:33.283 0: HMUARTLGW sys_culHm roundtrip delay: 0.0073
2019.01.06 21:35:46.889 0: HMUARTLGW sys_culHm roundtrip delay: 0.0151
2019.01.06 21:35:48.288 0: HMUARTLGW sys_culHm roundtrip delay: 0.0075
2019.01.06 21:36:03.633 0: HMUARTLGW sys_culHm roundtrip delay: 0.3464
2019.01.06 21:36:18.301 0: HMUARTLGW sys_culHm roundtrip delay: 0.0083
2019.01.06 21:36:33.468 0: HMUARTLGW sys_culHm roundtrip delay: 0.1709
2019.01.06 21:36:48.584 0: HMUARTLGW sys_culHm roundtrip delay: 0.2814
2019.01.06 21:37:03.636 0: HMUARTLGW sys_culHm roundtrip delay: 0.3276
2019.01.06 21:37:18.320 0: HMUARTLGW sys_culHm roundtrip delay: 0.0072
2019.01.06 21:37:33.537 0: HMUARTLGW sys_culHm roundtrip delay: 0.2199
2019.01.06 21:37:48.329 0: HMUARTLGW sys_culHm roundtrip delay: 0.0065
2019.01.06 21:38:03.335 0: HMUARTLGW sys_culHm roundtrip delay: 0.0078
2019.01.06 21:38:18.340 0: HMUARTLGW sys_culHm roundtrip delay: 0.0089
2019.01.06 21:38:33.535 0: HMUARTLGW sys_culHm roundtrip delay: 0.2000
2019.01.06 21:39:03.352 0: HMUARTLGW sys_culHm roundtrip delay: 0.0086
2019.01.06 21:39:18.538 0: HMUARTLGW sys_culHm roundtrip delay: 0.1904
2019.01.06 21:39:33.827 0: HMUARTLGW sys_culHm roundtrip delay: 0.4752
2019.01.06 21:39:48.379 0: HMUARTLGW sys_culHm roundtrip delay: 0.0237
2019.01.06 21:40:03.068 0: HMUARTLGW sys_culHm roundtrip delay: 0.0127
2019.01.06 21:40:03.365 0: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.06 21:40:18.371 0: HMUARTLGW sys_culHm roundtrip delay: 0.0080


Also schwanken sehr starken (zwischen 8 ms und knapp 500 ms) und sind mitunter eben auch ziemlich hoch (500 ms). Die RTT umfasst wohl die Zeit vom Senden eines Befehls bis zum Empfang der Antwort. Ist halt ziemlich hoch. Da ist es manchmal schwierig das Empfangsfenster des Peers zu treffen. Das sind außerdem Bereiche, die man auch wirklich als Mensch schon als Verzögerung wahrnehmen kann.

Kann das vom Datenhandling innerhalb des Maple kommen?

Ich halte das für unnormal oder ist das bei euch auch so? Die Ausgaben bekommt man, mit dem Attribut "logIDs" auf "sys".
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Januar 2019, 16:22:10
Teste mal die angehängte Version. Die seriellen Schnittstellen laufen damit komplett Interruptgesteuert. In der bisherigen Version kann eine RF Übertragung die serielle Übertragung ausbremsen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 07 Januar 2019, 19:51:49
Wow, danke, das war schnell! Hab leider wenig gutes zu berichten, fürchte ich:
2019.01.07 19:10:13.903 0: HMUARTLGW sys_culHm roundtrip delay: 0.0071
2019.01.07 19:10:28.911 0: HMUARTLGW sys_culHm roundtrip delay: 0.0069
2019.01.07 19:10:43.919 0: HMUARTLGW sys_culHm roundtrip delay: 0.0086
2019.01.07 19:10:58.933 0: HMUARTLGW sys_culHm roundtrip delay: 0.0146
2019.01.07 19:11:14.230 0: HMUARTLGW sys_culHm roundtrip delay: 0.3062
2019.01.07 19:11:29.029 0: HMUARTLGW sys_culHm roundtrip delay: 0.0961
2019.01.07 19:11:44.087 0: HMUARTLGW sys_culHm roundtrip delay: 0.1450
2019.01.07 19:11:59.073 0: HMUARTLGW sys_culHm roundtrip delay: 0.1243
2019.01.07 19:12:14.059 0: HMUARTLGW sys_culHm roundtrip delay: 0.1038
2019.01.07 19:12:29.191 0: HMUARTLGW sys_culHm roundtrip delay: 0.2310
2019.01.07 19:12:43.975 0: HMUARTLGW sys_culHm roundtrip delay: 0.0073
2019.01.07 19:12:58.978 0: HMUARTLGW sys_culHm roundtrip delay: 0.0076
2019.01.07 19:13:14.059 0: HMUARTLGW sys_culHm roundtrip delay: 0.0809
2019.01.07 19:13:28.992 0: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.07 19:13:44.435 0: HMUARTLGW sys_culHm roundtrip delay: 0.4430
2019.01.07 19:13:59.232 0: HMUARTLGW sys_culHm roundtrip delay: 0.2360
2019.01.07 19:14:14.531 0: HMUARTLGW sys_culHm roundtrip delay: 0.5297
2019.01.07 19:14:29.496 0: HMUARTLGW sys_culHm roundtrip delay: 0.4895
2019.01.07 19:14:44.018 0: HMUARTLGW sys_culHm roundtrip delay: 0.0078
2019.01.07 19:14:59.072 0: HMUARTLGW sys_culHm roundtrip delay: 0.0581
2019.01.07 19:15:14.640 0: HMUARTLGW sys_culHm roundtrip delay: 0.6197
2019.01.07 19:15:29.265 0: HMUARTLGW sys_culHm roundtrip delay: 0.2395
2019.01.07 19:15:44.576 0: HMUARTLGW sys_culHm roundtrip delay: 0.5462
2019.01.07 19:15:59.230 0: HMUARTLGW sys_culHm roundtrip delay: 0.1948
2019.01.07 19:16:14.047 0: HMUARTLGW sys_culHm roundtrip delay: 0.0067
2019.01.07 19:16:29.408 0: HMUARTLGW sys_culHm roundtrip delay: 0.3605
2019.01.07 19:16:44.058 0: HMUARTLGW sys_culHm roundtrip delay: 0.0073
2019.01.07 19:16:59.079 0: HMUARTLGW sys_culHm roundtrip delay: 0.0237
2019.01.07 19:17:14.066 0: HMUARTLGW sys_culHm roundtrip delay: 0.0080
2019.01.07 19:17:29.070 0: HMUARTLGW sys_culHm roundtrip delay: 0.0078
2019.01.07 19:17:44.074 0: HMUARTLGW sys_culHm roundtrip delay: 0.0071
2019.01.07 19:17:59.078 0: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.07 19:18:14.084 0: HMUARTLGW sys_culHm roundtrip delay: 0.0069
2019.01.07 19:18:29.086 0: HMUARTLGW sys_culHm roundtrip delay: 0.0063
2019.01.07 19:18:44.265 0: HMUARTLGW sys_culHm roundtrip delay: 0.1791
2019.01.07 19:18:59.287 0: HMUARTLGW sys_culHm roundtrip delay: 0.1978
2019.01.07 19:19:14.576 0: HMUARTLGW sys_culHm roundtrip delay: 0.4800
2019.01.07 19:19:29.315 0: HMUARTLGW sys_culHm roundtrip delay: 0.2150
2019.01.07 19:19:44.739 0: HMUARTLGW sys_culHm roundtrip delay: 0.6310
2019.01.07 19:19:59.119 0: HMUARTLGW sys_culHm roundtrip delay: 0.0072
2019.01.07 19:20:14.125 0: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.07 19:20:29.252 0: HMUARTLGW sys_culHm roundtrip delay: 0.1282
2019.01.07 19:20:44.136 0: HMUARTLGW sys_culHm roundtrip delay: 0.0068
2019.01.07 19:20:59.493 0: HMUARTLGW sys_culHm roundtrip delay: 0.3594
2019.01.07 19:21:14.276 0: HMUARTLGW sys_culHm roundtrip delay: 0.1385
2019.01.07 19:21:29.281 0: HMUARTLGW sys_culHm roundtrip delay: 0.1376
2019.01.07 19:21:44.242 0: HMUARTLGW sys_culHm roundtrip delay: 0.0922
2019.01.07 19:22:14.171 0: HMUARTLGW sys_culHm roundtrip delay: 0.0104
2019.01.07 19:22:29.325 0: HMUARTLGW sys_culHm roundtrip delay: 0.1568
2019.01.07 19:22:44.266 0: HMUARTLGW sys_culHm roundtrip delay: 0.0931
2019.01.07 19:22:59.187 0: HMUARTLGW sys_culHm roundtrip delay: 0.0100
2019.01.07 19:23:14.189 0: HMUARTLGW sys_culHm roundtrip delay: 0.0067
2019.01.07 19:23:29.327 0: HMUARTLGW sys_culHm roundtrip delay: 0.0610
2019.01.07 19:23:47.283 0: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.07 19:24:02.686 0: HMUARTLGW sys_culHm roundtrip delay: 0.4054
2019.01.07 19:24:17.355 0: HMUARTLGW sys_culHm roundtrip delay: 0.0682
2019.01.07 19:24:23.655 0: HMUARTLGW sys_culHm roundtrip delay: 0.0078
2019.01.07 19:24:32.297 0: HMUARTLGW sys_culHm roundtrip delay: 0.0072
2019.01.07 19:24:47.631 0: HMUARTLGW sys_culHm roundtrip delay: 0.3335
2019.01.07 19:25:02.478 0: HMUARTLGW sys_culHm roundtrip delay: 0.1764
2019.01.07 19:25:17.732 0: HMUARTLGW sys_culHm roundtrip delay: 0.4239
2019.01.07 19:25:32.317 0: HMUARTLGW sys_culHm roundtrip delay: 0.0068
2019.01.07 19:25:47.711 0: HMUARTLGW sys_culHm roundtrip delay: 0.3928
2019.01.07 19:26:02.526 0: HMUARTLGW sys_culHm roundtrip delay: 0.2028
2019.01.07 19:26:17.570 0: HMUARTLGW sys_culHm roundtrip delay: 0.2433
2019.01.07 19:26:32.914 0: HMUARTLGW sys_culHm roundtrip delay: 0.5822
2019.01.07 19:26:47.363 0: HMUARTLGW sys_culHm roundtrip delay: 0.0271
2019.01.07 19:27:02.992 0: HMUARTLGW sys_culHm roundtrip delay: 0.6528
2019.01.07 19:27:17.351 0: HMUARTLGW sys_culHm roundtrip delay: 0.0071
2019.01.07 19:27:32.355 0: HMUARTLGW sys_culHm roundtrip delay: 0.0069
2019.01.07 19:27:47.362 0: HMUARTLGW sys_culHm roundtrip delay: 0.0069
2019.01.07 19:28:02.370 0: HMUARTLGW sys_culHm roundtrip delay: 0.0091
2019.01.07 19:28:32.678 0: HMUARTLGW sys_culHm roundtrip delay: 0.3058
2019.01.07 19:28:47.691 0: HMUARTLGW sys_culHm roundtrip delay: 0.3131
2019.01.07 19:29:02.570 0: HMUARTLGW sys_culHm roundtrip delay: 0.1886
2019.01.07 19:29:17.396 0: HMUARTLGW sys_culHm roundtrip delay: 0.0080
2019.01.07 19:29:32.759 0: HMUARTLGW sys_culHm roundtrip delay: 0.3627
2019.01.07 19:29:47.910 0: HMUARTLGW sys_culHm roundtrip delay: 0.5095
2019.01.07 19:30:02.577 0: HMUARTLGW sys_culHm roundtrip delay: 0.1716
2019.01.07 19:30:17.421 0: HMUARTLGW sys_culHm roundtrip delay: 0.0087
2019.01.07 19:30:32.424 0: HMUARTLGW sys_culHm roundtrip delay: 0.0071
2019.01.07 19:30:47.682 0: HMUARTLGW sys_culHm roundtrip delay: 0.2597
2019.01.07 19:31:02.435 0: HMUARTLGW sys_culHm roundtrip delay: 0.0080
2019.01.07 19:31:17.793 0: HMUARTLGW sys_culHm roundtrip delay: 0.3605
2019.01.07 19:31:32.579 0: HMUARTLGW sys_culHm roundtrip delay: 0.1449
2019.01.07 19:31:47.670 0: HMUARTLGW sys_culHm roundtrip delay: 0.2253
2019.01.07 19:32:02.989 0: HMUARTLGW sys_culHm roundtrip delay: 0.5388
2019.01.07 19:32:17.468 0: HMUARTLGW sys_culHm roundtrip delay: 0.0103
2019.01.07 19:32:33.047 0: HMUARTLGW sys_culHm roundtrip delay: 0.5814
2019.01.07 19:32:47.659 0: HMUARTLGW sys_culHm roundtrip delay: 0.1867
2019.01.07 19:33:02.486 0: HMUARTLGW sys_culHm roundtrip delay: 0.0087
2019.01.07 19:33:17.844 0: HMUARTLGW sys_culHm roundtrip delay: 0.3596
2019.01.07 19:33:32.497 0: HMUARTLGW sys_culHm roundtrip delay: 0.0075
2019.01.07 19:33:47.569 0: HMUARTLGW sys_culHm roundtrip delay: 0.0734
2019.01.07 19:34:02.578 0: HMUARTLGW sys_culHm roundtrip delay: 0.0758
2019.01.07 19:34:17.524 0: HMUARTLGW sys_culHm roundtrip delay: 0.0080
2019.01.07 19:34:33.030 0: HMUARTLGW sys_culHm roundtrip delay: 0.5015
2019.01.07 19:34:47.937 0: HMUARTLGW sys_culHm roundtrip delay: 0.3966
2019.01.07 19:35:02.555 0: HMUARTLGW sys_culHm roundtrip delay: 0.0083
2019.01.07 19:35:17.576 0: HMUARTLGW sys_culHm roundtrip delay: 0.0254
2019.01.07 19:35:32.913 0: HMUARTLGW sys_culHm roundtrip delay: 0.3565
2019.01.07 19:35:48.223 0: HMUARTLGW sys_culHm roundtrip delay: 0.6595
2019.01.07 19:36:02.585 0: HMUARTLGW sys_culHm roundtrip delay: 0.0138
2019.01.07 19:36:17.905 0: HMUARTLGW sys_culHm roundtrip delay: 0.3244
2019.01.07 19:36:32.721 0: HMUARTLGW sys_culHm roundtrip delay: 0.1369
2019.01.07 19:36:48.229 0: HMUARTLGW sys_culHm roundtrip delay: 0.6382
2019.01.07 19:37:02.603 0: HMUARTLGW sys_culHm roundtrip delay: 0.0065
2019.01.07 19:37:17.775 0: HMUARTLGW sys_culHm roundtrip delay: 0.1725
2019.01.07 19:37:32.614 0: HMUARTLGW sys_culHm roundtrip delay: 0.0081
2019.01.07 19:37:47.636 0: HMUARTLGW sys_culHm roundtrip delay: 0.0265
2019.01.07 19:38:02.746 0: HMUARTLGW sys_culHm roundtrip delay: 0.1312
2019.01.07 19:38:17.731 0: HMUARTLGW sys_culHm roundtrip delay: 0.1097
2019.01.07 19:38:33.226 0: HMUARTLGW sys_culHm roundtrip delay: 0.5984
2019.01.07 19:38:47.640 0: HMUARTLGW sys_culHm roundtrip delay: 0.0072
2019.01.07 19:39:02.643 0: HMUARTLGW sys_culHm roundtrip delay: 0.0082
2019.01.07 19:39:17.649 0: HMUARTLGW sys_culHm roundtrip delay: 0.0091
2019.01.07 19:39:32.791 0: HMUARTLGW sys_culHm roundtrip delay: 0.1460
2019.01.07 19:39:47.741 0: HMUARTLGW sys_culHm roundtrip delay: 0.0920
2019.01.07 19:40:02.921 0: HMUARTLGW sys_culHm roundtrip delay: 0.2665
2019.01.07 19:40:17.747 0: HMUARTLGW sys_culHm roundtrip delay: 0.0903
2019.01.07 19:40:32.668 0: HMUARTLGW sys_culHm roundtrip delay: 0.0073
2019.01.07 19:40:47.672 0: HMUARTLGW sys_culHm roundtrip delay: 0.0067
2019.01.07 19:41:03.033 0: HMUARTLGW sys_culHm roundtrip delay: 0.3611
2019.01.07 19:41:17.987 0: HMUARTLGW sys_culHm roundtrip delay: 0.3058
2019.01.07 19:41:32.921 0: HMUARTLGW sys_culHm roundtrip delay: 0.2380
2019.01.07 19:41:47.734 0: HMUARTLGW sys_culHm roundtrip delay: 0.0427
2019.01.07 19:42:02.703 0: HMUARTLGW sys_culHm roundtrip delay: 0.0072
2019.01.07 19:42:18.249 0: HMUARTLGW sys_culHm roundtrip delay: 0.5446
2019.01.07 19:42:33.044 0: HMUARTLGW sys_culHm roundtrip delay: 0.3327
2019.01.07 19:42:47.898 0: HMUARTLGW sys_culHm roundtrip delay: 0.1823
2019.01.07 19:43:03.015 0: HMUARTLGW sys_culHm roundtrip delay: 0.2926
2019.01.07 19:43:17.738 0: HMUARTLGW sys_culHm roundtrip delay: 0.0066
2019.01.07 19:43:33.159 0: HMUARTLGW sys_culHm roundtrip delay: 0.4212
2019.01.07 19:43:41.139 0: HMUARTLGW sys_culHm roundtrip delay: 0.0108
2019.01.07 19:43:47.751 0: HMUARTLGW sys_culHm roundtrip delay: 0.0064
2019.01.07 19:44:03.760 0: HMUARTLGW sys_culHm roundtrip delay: 0.0080
2019.01.07 19:44:18.762 0: HMUARTLGW sys_culHm roundtrip delay: 0.0078
2019.01.07 19:44:34.126 0: HMUARTLGW sys_culHm roundtrip delay: 0.3650
2019.01.07 19:44:48.839 0: HMUARTLGW sys_culHm roundtrip delay: 0.0755
2019.01.07 19:45:03.919 0: HMUARTLGW sys_culHm roundtrip delay: 0.1481


Ich bin mir halt wirklich nicht sicher, was diese roundtrip delays genau bedeuten bzw. umfassen. Also nicht auszuschließen, dass das Problem noch woanders liegt. Wobei frank Werte um die 7 ms hat, wenn er den HM-MOD-UART direkt an eine Schnittstelle hängt, also ohne Maple dazwischen.

Wäre es aufwendig, testweise eine Version zu machen, die ausschließlich die HM-Schnittstelle bedient, um mal alle anderen Faktoren auszuschließen? Nur so als Idee.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Januar 2019, 20:01:16
Setze mal bei den CUL Devices das dummy Attribut auf 1 und mach einen Reset am MapleCUL. Die RF Transceiver müssten dann uninitialisiert und deaktiviert bleiben.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 07 Januar 2019, 20:12:17
Das ist super, ändert aber leider nix :(
2019.01.07 20:09:04.576 0: HMUARTLGW sys_culHm roundtrip delay: 0.0089
2019.01.07 20:09:19.701 0: HMUARTLGW sys_culHm roundtrip delay: 0.1269
2019.01.07 20:09:34.845 0: HMUARTLGW sys_culHm roundtrip delay: 0.2641
2019.01.07 20:09:49.593 0: HMUARTLGW sys_culHm roundtrip delay: 0.0071
2019.01.07 20:10:04.968 0: HMUARTLGW sys_culHm roundtrip delay: 0.3746
2019.01.07 20:10:19.927 0: HMUARTLGW sys_culHm roundtrip delay: 0.3302
2019.01.07 20:10:34.684 0: HMUARTLGW sys_culHm roundtrip delay: 0.0825
2019.01.07 20:10:50.239 0: HMUARTLGW sys_culHm roundtrip delay: 0.6339
2019.01.07 20:11:04.943 0: HMUARTLGW sys_culHm roundtrip delay: 0.3328
2019.01.07 20:11:19.644 0: HMUARTLGW sys_culHm roundtrip delay: 0.0291


EDIT:
Hier der Post von frank:
https://forum.fhem.de/index.php/topic,54511.msg882807.html#msg882807
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Januar 2019, 20:14:33
Laufen noch andere Geräte am USB Bus? Eventuell die auch mal deaktivieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 07 Januar 2019, 20:21:43
Hab mal alles andere vom Rechner abgesteckt, aber keine Änderung.

Das FHEM läuft in einer Ubuntu-VM in einem Win10-Host. Aber bisher keine Probleme gehabt mit HM-CFG-USB und RfxTrx433. War immer alles gefühlt sehr zügig. Sollte daher passen. Rechner ist ein i5 mit 3.5 GHz, sollte also auch genug Reserven haben.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Januar 2019, 20:25:53
Dann solltest du den HM-MOD-UART mal an einem anderen USB Wandler ausprobieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 07 Januar 2019, 20:30:41
Ok, werde ich machen. Komme da aber erst in ein paar Tagen zu.

Andere Frage: Wie sehen denn die Werte bei euch aus? Tritt das nur bei mir auf?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 07 Januar 2019, 22:56:21
Hat mir keine Ruhe gelassen... hab es noch schnell angeschlossen... krieg es aber natürlich gar nicht zum Laufen.

Dacht ich wäre schlau und ich muss evtl. den HM-UART gar nicht von der Maple-Platine runterlöten und hab den USB-UART gleich da auf der Platine angeschlossen. Hab alle Pins gemessen und ist meiner Meinung nach korrekt. Also 3,3 V VCC, GND, RX und TX.
Geht das prinzipiell so oder ist das ne blöde Idee?  :o

Was mich stutzig macht, ist die Messung auf dem Oszilloskop. Das ist die RX-Leitung des HM-UART. Ich hätte eigentlich gedacht, dass der Pegel zwischen den 3,3 V und 0 V wechselt. Aber der Pegel geht nur bis 2,7 V runter wenn ich was sende. Kann mir jemand einen Tip geben? Danke!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 08 Januar 2019, 08:44:16
Ok, hab es jetzt doch runter gelötet. Und ich glaub dabei haben sich ein paar Pads verabschiedet  :-\

Aber jetzt habe ich den HM-MOD-UART direkt per USB-Adapter am Rechner, ohne Maple und die RTTs sehen jetzt tatsächlich wesentlich besser aus:
2019.01.08 08:36:15.050 5: HMUARTLGW sys_culHm roundtrip delay: 0.0039
2019.01.08 08:36:30.060 5: HMUARTLGW sys_culHm roundtrip delay: 0.0070
2019.01.08 08:36:45.065 5: HMUARTLGW sys_culHm roundtrip delay: 0.0093
2019.01.08 08:38:05.711 0: HMUARTLGW sys_culHm roundtrip delay: 0.0052
2019.01.08 08:38:20.719 0: HMUARTLGW sys_culHm roundtrip delay: 0.0084
2019.01.08 08:38:35.728 0: HMUARTLGW sys_culHm roundtrip delay: 0.0088
2019.01.08 08:38:50.735 0: HMUARTLGW sys_culHm roundtrip delay: 0.0113
2019.01.08 08:39:05.744 0: HMUARTLGW sys_culHm roundtrip delay: 0.0113
2019.01.08 08:39:20.751 0: HMUARTLGW sys_culHm roundtrip delay: 0.0154
2019.01.08 08:39:35.747 0: HMUARTLGW sys_culHm roundtrip delay: 0.0059
2019.01.08 08:39:50.754 0: HMUARTLGW sys_culHm roundtrip delay: 0.0085
2019.01.08 08:40:05.762 0: HMUARTLGW sys_culHm roundtrip delay: 0.0126
2019.01.08 08:40:20.771 0: HMUARTLGW sys_culHm roundtrip delay: 0.0153
2019.01.08 08:40:35.778 0: HMUARTLGW sys_culHm roundtrip delay: 0.0183
2019.01.08 08:40:50.779 0: HMUARTLGW sys_culHm roundtrip delay: 0.0155
2019.01.08 08:41:05.787 0: HMUARTLGW sys_culHm roundtrip delay: 0.0124
2019.01.08 08:41:20.784 0: HMUARTLGW sys_culHm roundtrip delay: 0.0055


Also scheint wohl tatsächlich am MapleCUL zu liegen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Januar 2019, 12:52:11
Es muss aber auch an deinem System liegen. An einem Raspberry Pi sehen die Zeiten vom MapleCUL normal aus:

2019.01.08 11:44:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0077
2019.01.08 11:44:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:44:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:45:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0076
2019.01.08 11:45:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0066
2019.01.08 11:45:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:45:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0075
2019.01.08 11:46:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0076
2019.01.08 11:46:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0065
2019.01.08 11:46:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0064
2019.01.08 11:46:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0076
2019.01.08 11:47:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0065
2019.01.08 11:47:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0083
2019.01.08 11:47:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0079
2019.01.08 11:47:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:48:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:48:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0075
2019.01.08 11:48:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0073
2019.01.08 11:48:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:49:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0069
2019.01.08 11:49:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0080
2019.01.08 11:49:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0075
2019.01.08 11:49:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0073
2019.01.08 11:50:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:50:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0069
2019.01.08 11:50:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0076
2019.01.08 11:50:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0070
2019.01.08 11:51:01 0: HMUARTLGW myHmUART roundtrip delay: 0.0074
2019.01.08 11:51:16 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:51:31 0: HMUARTLGW myHmUART roundtrip delay: 0.0071
2019.01.08 11:51:46 0: HMUARTLGW myHmUART roundtrip delay: 0.0081
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 08 Januar 2019, 13:13:16
Ok danke, sehr interessant. Heißt einerseits, dass es prinzipiell geht. Andererseits hab ich erstmal keine Idee, warum der bei mir mit dem Maple so Zicken macht :(

Welche Firmware war das bei deinem Test? Die gestern angehängte?
Und welche Hardware hast du an dem Maple dran? Nur den HM-MOD-UART? Und in FHEM vermtl. auch nur den HMUARTLGW definiert?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Januar 2019, 13:40:29
Die Firmware ist die von gestern. Und die FHEM Konfiguration ist sehr reduziert:

attr global userattr alexaName alexaRoom cmdIcon devStateIcon devStateStyle fp_Heizung genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock homebridgeMapping:textField-long icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global commandref modular
attr global exclude_from_update 21_VBUSDEV.pm 19_VBUSIF.pm
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
WEB has no associated allowed device with basicAuth.\
telnetPort has no associated allowed device with password/globalpassword.\
\
Restart FHEM for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\

attr global room System
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3
#attr global backupdir /media/fritzbox-usb/raspberry

define telnetPort telnet 7073 global
attr telnetPort room System

define WEB FHEMWEB 8083 global
attr WEB hiddenroom DashboardRoom
attr WEB room System


# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
attr Logfile room System

define autocreate autocreate
attr autocreate disable 0
attr autocreate room System

define eventTypes eventTypes ./log/eventTypes.txt
attr eventTypes room System

# Disable this to avoid looking for new USB devices on startup
# define initialUsbCheck notify global:INITIALIZED usb create
define CUL_0 CUL /dev/serial/by-id/usb-STM32_MapleCUL_68e0d57e-if00@9600 1122
attr CUL_0 rfmode SlowRF
attr CUL_0 room System
attr CUL_0 verbose 3


define myHmUART HMUARTLGW /dev/serial/by-id/usb-STM32_MapleCUL_68e0d57e-if02@115200
attr myHmUART hmId F11135
attr myHmUART logIDs sys
attr myHmUART room System
attr myHmUART verbose 3
define FHT_282a FHT 282a
attr FHT_282a IODev CUL_0
attr FHT_282a room FHT
define FHT_311c FHT 311c
attr FHT_311c IODev CUL_0
attr FHT_311c room FHT
define FHT_3755 FHT 3755
attr FHT_3755 IODev CUL_0
attr FHT_3755 room FHT
define CUL_WS_1 CUL_WS 1
attr CUL_WS_1 room CUL_WS
define KS300 KS300 1234
attr KS300 IODev CUL_0
attr KS300 room KS300
define CUL_EM_4 CUL_EM 4
attr CUL_EM_4 IODev CUL_0
attr CUL_EM_4 room CUL_EM
define CUL_WS_5 CUL_WS 5
attr CUL_WS_5 room CUL_WS
define vccu CUL_HM F11135
attr vccu IODev myHmUART
attr vccu IOList myHmUART
attr vccu IOgrp vccu
attr vccu expert 2_raw
attr vccu model CCU-FHEM
attr vccu room System
attr vccu subType virtual
attr vccu webCmd virtual:update
define Aussen_TH_HUM CUL_HM 2F24D0
attr Aussen_TH_HUM IODev myHmUART
attr Aussen_TH_HUM IOgrp vccu
attr Aussen_TH_HUM autoReadReg 4_reqStatus
attr Aussen_TH_HUM expert 2_raw
attr Aussen_TH_HUM genericDeviceType thermometer
attr Aussen_TH_HUM model HM-WDS10-TH-O
attr Aussen_TH_HUM peerIDs 00000000,
attr Aussen_TH_HUM subType THSensor
define CUL_WS_2 CUL_WS 2
attr CUL_WS_2 room CUL_WS
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 08 Januar 2019, 13:58:40
Ok, danke, werde ich mal genau so nachbauen mit einem frischen Maple. Hattest du weitere Hardware außer dem HM-MOD-UART am Maple?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 08 Januar 2019, 14:05:09
Am MapleCUL waren zwei RF Module und der HM-MOD-UART angeschlossen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 08 Januar 2019, 14:57:40
Hi,
Ich tippe auf die vmware! Wie hast du die usb bereitgestellt? Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 08 Januar 2019, 15:05:53
Habe einfach den MapleCUL an den Host gesteckt und dann in VMWare an den Guest connectet. Also der Guest hat direkt das USB-Device bekommen und dafür entsprechend die Treiber geladen.. Auf die gleiche Art hab ich aber auch den USB-Serial-Wandler angeschlossen, mit dem dann die Latenzen aber gut waren:
https://forum.fhem.de/index.php/topic,60458.msg883623.html#msg883623
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 09 Januar 2019, 09:35:25
Ich hab nochmal einen anderen Maple genommen und da den HM-MOD-UART angeschlossen und das dann mit Telekatz' FHEM-Config laufen lassen, aber leider gleiches Verhalten  :(

Hab aber was interessantes rausgefunden:
ich hab mal ein simples C++-Testprogramm (https://gist.github.com/verybadsoldier/049597bd2251a330574fef1a4a6da2dd) geschrieben, welches nur die Credits-Anfrage an den HM-UART schickt, auf die Antwort wartet und die vergangene Zeit stoppt (das gleiche was die roundtrip-Time in FHEM macht). Das Ganze mache ich in einer Schleife mit einem random-Sleep zwischen den einzelnen Durchläufen.

Das sieht dann so aus (also immer die Angabe der Pause und die daraufhin gemessene RTT, die ich hier "RRT" nenne ;)):
Slept: 3.064 s RRT: 288
Slept: 3.27 s RRT: 80
Slept: 2.006 s RRT: 13
Slept: 3.003 s RRT: 348
Slept: 1.819 s RRT: 7
Slept: 3.465 s RRT: 230
Slept: 2.318 s RRT: 33
Slept: 1.535 s RRT: 7
Slept: 1.714 s RRT: 7
Slept: 3.285 s RRT: 67
Slept: 2.909 s RRT: 442
Slept: 2.477 s RRT: 215
Slept: 2.879 s RRT: 474
Slept: 2.822 s RRT: 530
Slept: 2.826 s RRT: 526
Slept: 2.156 s RRT: 23
Slept: 1.963 s RRT: 6
Slept: 3.241 s RRT: 111
Slept: 2.151 s RRT: 29
Slept: 2.937 s RRT: 414
Slept: 3.382 s RRT: 313
Slept: 2.206 s RRT: 143
Slept: 3.013 s RRT: 339
Slept: 2.837 s RRT: 513
Slept: 2.785 s RRT: 566
Slept: 2.361 s RRT: 332
Slept: 2.919 s RRT: 433
Slept: 2.249 s RRT: 102


Man sieht, dass die roundtripetime super ist, solange die vorherige Abfrage weniger als 2 Sekunden zurück liegt. Sobald die Pause größer wird, entsteht bei der nächsten Abfrage eine Latenz.

Ich hab mal das FHEM-Modul so verändert, dass die RTT-Messungen nicht nur alle 15 Sek. passieren, sondern sekündlich. Und tatsächlich sind dann auch die RTT-Werte in FHEM super.

Also ich vermute sehr stark, dass sich da irgendwas nach 2 Sek. schlafen legt. Energiesparmodus oder sowas. Ich war mir sehr sicher, dass es dieser Kernel-Mechanismus ist, der USB-Geräte schlafen legen kann wenn sie idle sind:
https://www.kernel.org/doc/html/v4.16/driver-api/usb/power-management.html

Der Default-Wert ist tatsächlich 2000 ms. Würde also genau passen.
power/autosuspend_delay_ms

This file contains an integer value, which is the number of milliseconds the device should remain idle before the kernel will autosuspend it (the idle-delay time). The default is 2000. 0 means to autosuspend as soon as the device becomes idle, and negative values mean never to autosuspend. You can write a number to the file to change the autosuspend idle-delay time.


Passt auch dazu, dass ich mit einem "normalen" USB-Serial-Converter den Effekt nicht habe. Der benutzt eben einen anderen Linux-Treiber (nicht den cdc_acm). Könnte in dem Treiber anders implementiert sein. Das ist offenbar der Patch der autosuspend in den cdc_acm bringt:
https://www.systutorials.com/linux-kernels/151457/usb-autosuspend-for-cdc-acm-linux-2-6-25/

Ich finde, das passt alles. Aber blöderweise: Ich hab das Autosuspend jetzt schon auf drei Arten deaktiviert. Aber leider bleibt das Verhalten unverändert :( Also entweder ist es doch etwas anderes oder das Abschalten klappt nicht.

Telekatz für ein Linux benutzt und was für einen Kernel? Ich hab ein Ubuntu 18.04 mit Kernel 4.15.0-43.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 09 Januar 2019, 10:00:18
Es ist ein Raspbian Wheezy mit Kernel 4.1.19-v7+
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: frank am 09 Januar 2019, 11:34:00
@vbs
hast du anstatt ab zu schalten, mal versucht die 2000ms zu erhöhen? also zb auf 20000ms.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 09 Januar 2019, 13:06:40
Nee bisher noch nicht, aber werde ich gerne mal machen. Gefühlt habe ich jedoch nicht viel Hoffnung, muss ich sagen.

Für mich wäre der nächste Schritt, das Ganze mal auf einem älteren Kernel (aber weiterhin in einer VM) zu testen. Telekatz' Kernel ist auch etwas älter. Würde gerne wissen, ob es am Kernel oder VM liegt. Ich tippe ja (und hoffe) auf Kernel. Eigentlich passen für mich auch alle Indizien zusammen. Nur mit dem kleinen Haken, dass die Gegenmaßnahmen einfach nicht greifen :(
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 10 Januar 2019, 11:29:52
Es ist zum Weinen... bekomme es einfach nicht raus... hab das "autosuspend_delay" auf 50000 gedreht, aber auch keine Änderung. Eigentlich bin ich der Meinung, dass der ganze Mechanismus sowieso für das Device defaultmäßig ausgeschaltet ist laut sysfs.
Hab auch in Windows 10 ein "USB selective suspend" (https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices) gefunden. Ausschalten brachte aber auch nichts.

Nochmal kurz, was ich bisher getestet habe. Vielleicht fällt jemandem was dazu ein:
Sieht halt aus, als läge es an Windows 10 oder an der Kombination Windows10+VMWare. Dagegen spricht, dass es aber unter der Konstellation mit FTDI-Adapter anstatt MapleCUL trotzdem funktioniert.
Außerdem kann ich mich nur schwer damit abfinden, dass es nicht dieses Linux-autosuspend sein soll, weil es ja eben genau auf diese 2 Sekunden passt. Es scheint ja kein Bug vorzuliegen, sondern offenbar ein Mechanismus zu sein, der gezielt nach 2 Sekunden irgendwie eingreift und für so eine Delay sorgt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 10 Januar 2019, 12:53:07
Hallo vbs,
vielleicht das hier?
https://askubuntu.com/questions/185274/how-can-i-disable-usb-autosuspend-for-a-specific-device (https://askubuntu.com/questions/185274/how-can-i-disable-usb-autosuspend-for-a-specific-device)

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 10 Januar 2019, 13:30:24
Danke dir, aber leider keine Besserung :(
Für die autosuspend-Theorie spricht einerseits, dass es total Sinn macht und die 2 Sek. passen. Dagegen spricht aber, dass es in der Konstellation "Ubuntu 12.04 -> VMWare 9 -> Ubuntu 18.04 MapleCUL: OK" nicht auf tritt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: frank am 10 Januar 2019, 13:34:48
vielleich kannst du den ecomode vom usb im BIOS grundsätzlich verhindern.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 10 Januar 2019, 22:51:58
Hab ich geguckt, aber leider im BIOS nix dazu gefunden.

Hab jetzt mal auf nativem Windows 10 getestet und da ist es auch OK.


Also auch kein generelles Windows10-Thema... Sieht schon ein bisschen nach VM aus. Aber das USB-autosuspend geht mir nicht aus dem Kopf...

Ich werde langsam offtopic, fürchte ich. Könnt ihr es noch ertragen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 11 Januar 2019, 11:12:58
Ein Ansatz wäre vielleicht auch docker (https://github.com/fhem/fhem-docker/) .. sofern USB-Serial gehen sollte..
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 11 Januar 2019, 13:18:08
Ok danke, werde ich mir auch mal näher ansehen. Hab es mal mit Virtualbox getestet und damit ist es auch OK. Wäre also auch ein Weg... werde aber mit VMWare auch noch etwas rumtesten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 11 Januar 2019, 14:48:31
...und ich nutze USB im "LXC"...

Dazu gibt es im Forum auch ein paar nette Beschreibungen wie man da USB reinreicht.
Zum Beispiel https://forum.fhem.de/index.php/topic,78738
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 12 Januar 2019, 10:10:37
Zitat von: Ranseyer am 06 Januar 2019, 11:25:19
@Markus: Du nimmst
-den Schaltplan der Hauptplatine: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Archiv/V3.4/Schematic.png (und siehst das Homematic am UART1 ist)
-den Schaltplan des AddOns: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/AddOns/RFM69-usw-aktuell/schematic.png (da suchst du den Weg vom Arduino bis zum UART0)

Also wenn ich jetzt nicht total daneben gesehn habe: Keine Jumper ändern. Das war ja die Idee, Homematic-Modul und eine andere Sache möglichst ohne Jumper zu ändern...

Hallo Zusammen,
nochmal zurück zu dem Addon das als RFM69 MySensors Gateway laufen soll.... ;-)
Alos wenn ich mir die Addon Platine 1.1 hole und den Large 3.4... Wenn ich jetzt die Verbindung vom ProMini zur Hauptplatine suche, komme ich mit einer Durchgangsmessung auf folgendes Ergebnis, den Schaltplan mal ungeachtet..

Promini RX -> UART0 R (was ja richtig wäre)
Promini TX-> UART1 TX (und das verstehe ich nicht)

Die Jumper sind auf dem Addon Board nicht geändert.

Gruß

Markus



Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 12 Januar 2019, 12:24:56
So, funktioniert nun... eeeeeendlich  :o

Ich erspar euch mal die Details, aber ich hab noch einige Kombinationen aus Ubuntu/VMWare/Virtualbox trial&error-mäßig durchgetestet. Die Indikation war nicht eindeutig, aber VMware war irgendwie immer im Spiel. Hab dann lange mit VMware vmx-Config-Optionen rumgespielt (die leider nicht dokumentiert sind) und eine gefunden, die man setzen kann und die das Problem dann tatsächlich löst. Nennt sich "usb.activeTimeout" und wird in Mikrosekunden angegeben. Hab ich jetzt bei mir auf einen hohen Wert gesetzt und jetzt funktionierts :D

Slept: 2.007 s RRT: 6
Slept: 2.884 s RRT: 7
Slept: 2.229 s RRT: 6
Slept: 3.077 s RRT: 6
Slept: 3.412 s RRT: 7
Slept: 2.445 s RRT: 7
Slept: 1.569 s RRT: 7
Slept: 1.59 s RRT: 6
Slept: 1.681 s RRT: 6
Slept: 3.42 s RRT: 6
Slept: 2.22 s RRT: 7
Slept: 1.92 s RRT: 6
Slept: 2.319 s RRT: 8
Slept: 1.928 s RRT: 7


Mann mann mann, das war ein Ritt... Nochmals vielen Dank an alle für Ideen und Tipps!

EDIT:
Doch noch ein paar Details:
Configdatei der VM liegt im Verzeichnis der VM mit der Endung .vmx. Eine Liste der Config-Parameter gibt's hier:
https://www.basvanbeek.nl/linux/undocumented-vmware-vmx-parameters/

Der Parameter heißt usb.activeTimeout

Datentype is Integer (TRUE/FALSE funktioniert nicht). Einheit ist Mikrosekunden. Defaultwert scheint 2000000 (2 Sek.) zu sein. Ich hab bei mir einen möglichst hohen Wert eingetragen (damit des Device möglichst nie schlafen geht):
usb.activeTimeout = "1500000000"
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 12 Januar 2019, 18:51:02
Hi,
Daumen hoch für die Geduld beim suchen!
Und jetzt ergänze dich bitte in Code Tags oben die konkrete Zeile mit ,,hohem Wert" und den Config Dateinamen ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 13 Januar 2019, 09:02:37
Zitat von: Markus. am 12 Januar 2019, 10:10:37
Alos wenn ich mir die Addon Platine 1.1 hole und den Large 3.4... Wenn ich jetzt die Verbindung vom ProMini zur Hauptplatine suche, komme ich mit einer Durchgangsmessung auf folgendes Ergebnis, den Schaltplan mal ungeachtet..

Sch... Den Fehler kannte ich und habe den wohl vergessen zu beheben. Du muss also einen der Jumper umsetzen, so dass es zusammenpasst.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 13 Januar 2019, 10:21:50
Kann mir jemand sagen, auf welcher Basis die RSSI Werte im Reading angezeigt werden und wie ich diese aktualisieren kann? Ich würde gerne verschiedene Antennen mal mit den dargestellten Werten prüfen.

MapleCUN V3.3 Large, V 1.26.05 a-culfw Build: 311
1: 868MHz: Lacrosse/HMI
2: 433Mhz: SlowRF
3: 868MHz: HM
4: 868MHz: ./.
5.: HM-MOD-UART2

Konfiguration: Stackable_CC

Vielen Dank und schönen Sonntag,
dmq
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 13 Januar 2019, 11:10:28
Hier noch ein List des ersten Gerätes im Stack:

Internals:
   CFGFN     
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        N.N.N.N:2323 2222
   DeviceName N.N.N.N:2323
   FD         88
   FHTID      2222
   MAPLECUL_XX_MSGCNT 234750
   MAPLECUL_XX_TIME 2019-01-13 11:07:25
   NAME       MAPLECUL_XX
   NR         282650
   PARTIAL   
   RAWMSG     H432E00050249FF
   RSSI       -74.5
   STACKED    MAPLECUL_XX
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) MapleCUNx4_8F (F-Band: 868MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     C:SD_WS07  ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-01-13 08:58:17   ccconf          freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB
     2019-01-13 08:58:24   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2019-01-13 08:58:31   credit10ms      3600
     2019-01-13 09:44:53   raw             eaeedeaccgfadeeechceiaedacchegghgedddddddddcbjjjjiiiiccijjjjjjjjjjjjjjjjjibgejjjeeeejjjdcccccgjjjjjjjjjjjjjjiccgjjjjjiiiiiiiidciiiajjjjjjjjjjijiiaaiiiiaeeeedeeaahhhgacdeddcjgfaeeeedcafeiiiiicaeedchabeii*om81BFE10F3FFFE410EB
     2019-01-13 11:07:25   state           Initialized
     2019-01-12 18:40:36   uptime          0 00:03:23
     2019-01-13 08:59:10   version         V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) MapleCUNx4_8F (F-Band: 868MHz)
Attributes:
   addvaltrigger 1
   connectCommand Nr1
   room       Bridges
   verbose    1


Ich habe das Attribut addvaltrigger auf "1" gesetzt.

Ich verstehe nur nicht ganz, wann (Zeit, Ereignis) und wie (automatisch, manuell) ich diesen Wert auslesen kann.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 13 Januar 2019, 11:17:18
Ich habe mir die RSSI Werte nun mal in eine Datei schreiben lassen:

.*:RSSI.*

Für die Lacrosse-Geräte die ja im MapleCUN als HMS Geräte definiert werden, bekomme ich jetzt bei jeder Übertragung einen Wert: allerdings für alle immer den gleichen unveränderten Wert -74.5 :/
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 13 Januar 2019, 17:55:39
Ich habe jetzt bei den CC1101 Modulen folgende Werte:

1: 868MHz: Lacrosse/HMS: -74.5 RSSI
2: 433Mhz: SlowRF: -94 RSSI
3: 868MHz: HM: -39 RSSI
4: 868MHz: SlowRF: -33.5 RSSI

Alle Module haben die gleichen Antennen (bis auf die 433 MHz) und sind in der Art gleich verlötet mit SMA Konnektoren.

Kommt der Wert vom Modul oder vom Kommunikationspartner - es sind ein paar Dinger an ziemlich weiten fiesen Stellen dabei...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Leinad am 13 Januar 2019, 22:00:06
Ist mir auch schon aufgefallen... RSSI von -74,5 habe ich auch für alle meine LaCrosse Sensoren?! Egal ob neben der Antenne oder draußen im Garten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 14 Januar 2019, 21:43:57
Zitat von: Leinad am 13 Januar 2019, 22:00:06
Ist mir auch schon aufgefallen... RSSI von -74,5 habe ich auch für alle meine LaCrosse Sensoren?! Egal ob neben der Antenne oder draußen im Garten.

Danke - ich vermute die Frage ist dann leider wahrscheinlich auch in den Threads der einzelnen Gerätetypen/Sketches besser aufgehoben oder ggf. in den Quellcode gucken "lacrosse.c". Die 74.5 sind mir suspekt. Auf meinem Jeelink (+ TX29 IT) bekomme ich auch keine RSSI Werte, da der RFM12 das wohl nicht anbietet. Ich empfange grundsätzlich auch alle geplanten Sender, die ich mit dem Jeelink auch empfange. Also bin ich zufrieden. Ich hätte es halt nur gerne verstanden.

 
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 17 Januar 2019, 13:31:22
Hat schonmal jemand von euch ein HM-MOD-RPI-PCB Modul an der Platine von Ranseyer zum laufen bekommen? Hab jetzt das Modul aufgelötet. Alle Verbindungen haben Kontakt zu den STM32 Pins und irgendwie mag das Modul in FHEM nicht.

defmod myRemoteHmUART HMUARTLGW uart://192.168.1.153:2324
attr myRemoteHmUART room Gateways


2019.01.17 13:30:29 1: HMUARTLGW myRemoteHmUART did not respond for the 1. time, resending
2019.01.17 13:30:32 1: HMUARTLGW myRemoteHmUART did not respond for the 2. time, resending
2019.01.17 13:30:35 1: HMUARTLGW myRemoteHmUART did not respond for the 3. time, resending
2019.01.17 13:30:38 1: HMUARTLGW myRemoteHmUART did not respond after all, reopening
2019.01.17 13:30:38 1: 192.168.1.153:2324 reappeared (myRemoteHmUART)
2019.01.17 13:30:42 1: HMUARTLGW myRemoteHmUART did not respond for the 1. time, resending
2019.01.17 13:30:45 1: HMUARTLGW myRemoteHmUART did not respond for the 2. time, resending
2019.01.17 13:30:48 1: HMUARTLGW myRemoteHmUART did not respond for the 3. time, resending
2019.01.17 13:30:51 1: HMUARTLGW myRemoteHmUART did not respond after all, reopening
2019.01.17 13:30:51 1: 192.168.1.153:2324 reappeared (myRemoteHmUART)
2019.01.17 13:30:55 1: HMUARTLGW myRemoteHmUART did not respond for the 1. time, resending
2019.01.17 13:30:58 1: HMUARTLGW myRemoteHmUART did not respond for the 2. time, resending
2019.01.17 13:31:01 1: HMUARTLGW myRemoteHmUART did not respond for the 3. time, resending
2019.01.17 13:31:04 1: HMUARTLGW myRemoteHmUART did not respond after all, reopening
2019.01.17 13:31:04 1: 192.168.1.153:2324 reappeared (myRemoteHmUART)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Beta-User am 17 Januar 2019, 13:38:06
EDIT: Gelöscht - Hier vermutlich nicht das Problem.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 17 Januar 2019, 13:43:08
Zitat von: gloob am 17 Januar 2019, 13:31:22
Hat schonmal jemand von euch ein HM-MOD-RPI-PCB Modul an der Platine von Ranseyer zum laufen bekommen? Hab jetzt das Modul aufgelötet. Alle Verbindungen haben Kontakt zu den STM32 Pins und irgendwie mag das Modul in FHEM nicht.


Ja das läuft. Weil ich geizig bin habe ich nur zwei HM-MOD-UART. Der, der aktuell produktiv läuft stammt von dir und ist noch immer auf der Platine die du verlötet hast...
Welche Bitrate der UART am MAPLE per Default hat weiss ich nicht. Setze doch mal bitte ein "pi" ab...

Dann die Bitrate richtig einstellen und vor allem speichern siehe: https://wiki.fhem.de/wiki/MapleCUX-Platinen#Konfiguration_f.C3.BCr_die_AddOnPlatine
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 17 Januar 2019, 13:47:11
Zitat von: Ranseyer am 17 Januar 2019, 13:43:08

Ja das läuft. Weil ich geizig bin habe ich nur zwei HM-MOD-UART. Der, der aktuell produktiv läuft stammt von dir und ist noch immer auf der Platine die du verlötet hast...
Welche Bitrate der UART am MAPLE per Default hat weiss ich nicht. Setze doch mal bitte ein "pi" ab...

Dann die Bitrate richtig einstellen und vor allem speichern siehe: https://wiki.fhem.de/wiki/MapleCUX-Platinen#Konfiguration_f.C3.BCr_die_AddOnPlatine

Auf die Baudrate scheint er immerhin richtig eingestellt zu sein:

019.01.17 13:46:10 3: set MAPLECUL_21 raw pi
2019.01.17 13:46:10 5: SW: pi
2019.01.17 13:46:10 5: CUL/RAW: /0:115200
1:115200

2019.01.17 13:46:10 4: CUL_Parse: MAPLECUL_21 0 :1 15 200   


Eingebunden ist er über den Port 2324, sollte ja auch richtig sein.

Auf welchen Pins müsste ich denn beim Durchpiepsen landen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 17 Januar 2019, 13:50:40
Kann sein...  8)

Oder:
ZitatEin am UART1 angeschlossener HM-MOD-UART kann z.B. mit folgender Definition in FHEM eingebunden werden:
define myRemoteHmUART HMUARTLGW uart://192.168.42.23:2325
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 17 Januar 2019, 13:53:17
Zitat von: Ranseyer am 17 Januar 2019, 13:50:40
Kann sein...  8)

Oder:

Toll. Irgendwie war ich die ganze Zeit auf 2324 fixiert. Mit 2425 gibt es dann auch ein sinnvolles Ergebnis:

defmod myRemoteHmUART HMUARTLGW uart://192.168.1.153:2325
attr myRemoteHmUART room Gateways
attr myRemoteHmUART verbose 0

setstate myRemoteHmUART opened
setstate myRemoteHmUART 2019-01-17 13:52:31 D-HMIdOriginal 6A56C4
setstate myRemoteHmUART 2019-01-17 13:52:31 D-firmware 1.2.1 (outdated)
setstate myRemoteHmUART 2019-01-17 13:52:31 D-serialNr PEQ0533764
setstate myRemoteHmUART 2019-01-17 13:52:28 D-type HM-MOD-UART
setstate myRemoteHmUART 2019-01-17 13:52:31 cond ok
setstate myRemoteHmUART 2019-01-17 13:52:31 load 0
setstate myRemoteHmUART 2019-01-17 13:52:31 loadLvl low
setstate myRemoteHmUART 2019-01-17 13:52:28 state opened




Und dann macht man noch das Firmware Update und alles ist gut:

defmod myRemoteHmUART HMUARTLGW uart://192.168.1.153:2325
attr myRemoteHmUART room Gateways
attr myRemoteHmUART verbose 0

setstate myRemoteHmUART opened
setstate myRemoteHmUART 2019-01-17 13:59:07 D-HMIdOriginal 6A56C4
setstate myRemoteHmUART 2019-01-17 13:59:07 D-firmware 1.4.1
setstate myRemoteHmUART 2019-01-17 13:59:07 D-serialNr PEQ0533764
setstate myRemoteHmUART 2019-01-17 13:52:28 D-type HM-MOD-UART
setstate myRemoteHmUART 2019-01-17 13:59:07 cond ok
setstate myRemoteHmUART 2019-01-17 13:59:07 load 0
setstate myRemoteHmUART 2019-01-17 13:59:07 loadLvl low
setstate myRemoteHmUART 2019-01-17 13:58:40 state opened


Ich glaub ich muss mal die Schritte ins Wiki eintragen, wenn mir jemand die richtige Stelle nennt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 17 Januar 2019, 18:17:12
Bin zwar ein wenig spät, aber ja, bei mir läuft es auch unter :2325 UART2.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 17 Januar 2019, 18:27:22
Zitat von: gloob am 17 Januar 2019, 13:53:17
Ich glaub ich muss mal die Schritte ins Wiki eintragen, wenn mir jemand die richtige Stelle nennt.

Ich denke das hat mit dem MAPLE-CUL Projekt an sich nichts zu tun. Daher schlage ich vor: https://wiki.fhem.de/wiki/MapleCUX-Platinen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 19 Januar 2019, 16:42:33
hallo Zusammen,

ich hab auf dem Maple jetzt MAX auf Stamp 3 (1-4) laufen. Ein Fensterkontakt wurde auch sofort erkannt bei einer Aktion. Es wurde ein CUL_MAX angelegt und der Kontakt selber per autocreate. Denke mal das ist richtig so. Gibt es für den CUL_MAX oder den Fensterkontakt noch irgendwelche Settings die man machen sollte in Verbindung mit dem Maple?
Bei meinen Anfänglichen Tests habe bemerkt, das wenn man den Kontakt zu schnell/ zu oft öffnet oder schliesst, tut sich Garnichts mehr. Soll heissen, das der Zustand des Kontaktes nicht mehr registriert wird. Habe dann den Kontakt und den CUL_MAX gelöscht und neu angelegen lassen.
Nun läuft er eigentlich seit Stunden stabil.


Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 20 Januar 2019, 17:34:54
Hi,

kann es sein, dass der MapleCUN nur ein Socket (per Dienst) erlaubt? Wenn ich eine bestehende TCP-Verbindung auf :2323, :2324 und :2325 offen (ESTABLISHED) habe, bekomme ich bei allen weiteren versuchen darauf ein tcp rst.

Ist das bekannt? Gewollt? Konfigurierbar?

Danke vorab
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Rheingold am 20 Januar 2019, 18:40:00
Hi,

ich war so naiv und glaubte ein Update von FHEM an einem Sonntagabend sei eine gute Idee  ::) Das Resultat ist, dass mein Stacked CUL nicht mehr richtig funktioniert. Die ersten paar Minuten nach einem Neustart ist alles super, aber dann wenn ich ein paar Dinge schalte kommt im Log einfach nur

Zitat2019.01.20 18:35:00 1: FHEM:DEVIO:MAPLECUL868Stack:9600 disconnected, waiting to reappear (MAPLECUL433)

Geändert an der Hardware oder der config habe ich nichts. Die einzige Änderung war ein Update von FHEM. Gut, das letzte Update ist schon eine Weile her, aber nun ist der CUL irgendwie unbrauchbar geworden :(
Ein "Reopen" des MAPLECUL433 hilft nicht. Auch den Strom kurzzeitig trennen und dann ein "reopen" hat das gleiche Ergebnis.

Wer kann mir helfen? Ich bin ratlos was den Stacked CUL betrifft :( Das einzige was ich verstehe, ist dass der Stacked868 die Verbindung verliert. Den Grund verstehe ich nicht...

Definiert ist es wie folgt:
define MAPLECUL868 CUL 192.168.178.47:2323 4444
attr MAPLECUL868 model CUN
attr MAPLECUL868 rfmode SlowRF
attr MAPLECUL868 room 99_System,CUL
define MAPLECUL868Stack STACKABLE MAPLECUL868
attr MAPLECUL868Stack room CUL
define MAPLECUL433 CUL FHEM:DEVIO:MAPLECUL868Stack:9600 0000
attr MAPLECUL433 model CUN
attr MAPLECUL433 room CUL
define MAPLECUL433Stack STACKABLE MAPLECUL433
attr MAPLECUL433Stack room CUL


Danke schon mal :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 20 Januar 2019, 19:10:25
MapleCUN vom Strom trennen und wieder verbinden. Dann im FHEM ein shutdown restart. Dann sollte alles wieder gehen wenn deine config ok ist. Hab das auch schon paarmal gehabt da half nur ein fhem neustart. evtl ist da ein fehler in den CUL Modulen im FHEM das da irgend was hängen bleiben kann.
Und generell läuft bei mir STACKABLE_CC stabiler wie STACKABLE
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Rheingold am 20 Januar 2019, 19:12:11
Zitat von: Eistee am 20 Januar 2019, 19:10:25
MapleCUN vom Strom trennen und wieder verbinden. Dann im FHEM ein shutdown restart. Dann sollte alles wieder gehen wenn deine config ok ist. Hab das auch schon paarmal gehabt da half nur ein fhem neustart. evtl ist da ein fehler in den CUL Modulen im FHEM das da irgend was hängen bleiben kann.

Hi,
danke für die flotte Antwort. Ein Neustart von FHEM habe ich jetzt schon etwa 25 Mal gemacht. Erst funktioniert alles, aber sobald ich ein Device über diesen MAPLECUL433 schalten will, verabschiedet er sich (zusammen mit dem MAPLECUL868Stack). Stimmt meine zuvor geschriebene Config nicht? Wie gesagt, vor dem Update lief alles wunderbar.

Was mich wundert ist, dass der MAPLECUL868Stack plötzlich nicht mehr defined ist, sondern den Status 0 hat.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 20 Januar 2019, 19:19:29
Zitat von: dmq am 20 Januar 2019, 17:34:54
Hi,

kann es sein, dass der MapleCUN nur ein Socket (per Dienst) erlaubt? Wenn ich eine bestehende TCP-Verbindung auf :2323, :2324 und :2325 offen (ESTABLISHED) habe, bekomme ich bei allen weiteren versuchen darauf ein tcp rst.

Ist das bekannt? Gewollt? Konfigurierbar?

Danke vorab
Ja, das ist so gewollt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 20 Januar 2019, 19:23:14
ZitatJa, das ist so gewollt.

Ah, ok. Dann weiß ich bescheid. Danke. Ich wollte ursprünglich (interimsweise) mit zwei Geräten auf den Maple zugreifen. Aber dann mache ich das anders.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 20 Januar 2019, 19:26:10
Stimmt meine zuvor geschriebene Config nicht? Wie gesagt, vor dem Update lief alles wunderbar.

Ein kurzer Abgleich mit anderen Konfiguration sieht identisch aus. Ich setze STACKABLE_CC ein. Hast Du das alternativ mal probiert?

Beispiel hier:

https://forum.fhem.de/index.php/topic,95683.0.html
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: moerte am 20 Januar 2019, 19:45:33
Zitat von: Rheingold am 20 Januar 2019, 18:40:00

Geändert an der Hardware oder der config habe ich nichts. Die einzige Änderung war ein Update von FHEM. Gut, das letzte Update ist schon eine Weile her, aber nun ist der CUL irgendwie unbrauchbar geworden :(
Ein "Reopen" des MAPLECUL433 hilft nicht. Auch den Strom kurzzeitig trennen und dann ein "reopen" hat das gleiche Ergebnis.

Wer kann mir helfen? Ich bin ratlos was den Stacked CUL betrifft :( Das einzige was ich verstehe, ist dass der Stacked868 die Verbindung verliert. Den Grund verstehe ich nicht...


Ich hab keine Ahnung ob ich dir damit jetzt helfen kann .. kann dir aber sagen dass ich mit meinen MapleCUL genau das selbe Problem hatte.
Nach den Strom trennen war er wieder da ..sobald ich was schalten wollte ging er disconected.

Ich hatte ihn an einen Fritz Repeater per LAN.
Mir sind dann durch Zufall IP ungereimtheiten aufgefallen. In meinen Repeater stand eine ganz andere IP als in der Basisstation.

Hab ihn jetzt an die Basis und seit dem läuft er wie gewollt.
Was ich sagen möchte.. Schau mal ob sich vlt die IP geändert hat?

An der Konfiguration kann ich jetzt nichts falsches sehen

Lg
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Rheingold am 20 Januar 2019, 20:08:26
Zitat von: moerte am 20 Januar 2019, 19:45:33
Ich hab keine Ahnung ob ich dir damit jetzt helfen kann .. kann dir aber sagen dass ich mit meinen MapleCUL genau das selbe Problem hatte.
Nach den Strom trennen war er wieder da ..sobald ich was schalten wollte ging er disconected.

Ich hatte ihn an einen Fritz Repeater per LAN.
Mir sind dann durch Zufall IP ungereimtheiten aufgefallen. In meinen Repeater stand eine ganz andere IP als in der Basisstation.

Hab ihn jetzt an die Basis und seit dem läuft er wie gewollt.
Was ich sagen möchte.. Schau mal ob sich vlt die IP geändert hat?

An der Konfiguration kann ich jetzt nichts falsches sehen

Lg
Guter Tipp mit der IP, doch hat diese sich nicht verändert. Das Ding ist per Kabel direkt an einen Switch bzw. die Fritzbox angeschlossen.

Das mit STACKABLE_CC muss ich mal testen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: moerte am 20 Januar 2019, 20:24:04
Zitat von: Rheingold am 20 Januar 2019, 20:08:26

Das mit STACKABLE_CC muss ich mal testen.

Hab ich auch ..
Würde die Einrichtung nach Wiki machen an deiner Stelle ..
"Einrichtung in FHEM alt"

Da kann egtl nichts schief gehen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Rheingold am 20 Januar 2019, 21:57:22
Zitat von: moerte am 20 Januar 2019, 20:24:04
Hab ich auch ..
Würde die Einrichtung nach Wiki machen an deiner Stelle ..
"Einrichtung in FHEM alt"

Da kann egtl nichts schief gehen

Also mit dem Stackable_cc aus dieser Anleitung (https://forum.fhem.de/index.php/topic,95683.0.html) klappt es leider auch nicht. Ich bekomme nur den ersten CUL definiert, die stackables funktionieren leider nicht. Zeigen lediglich "Defined" an.

Was meinst du mit "Einrichtung in FHEM alt" ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 20 Januar 2019, 22:04:25
Er meinte im Wiki Eintrag: https://wiki.fhem.de/wiki/MapleCUN die Einrichtung in FHEM (alt) Sektion. Sollte aber auch nicht anders sein.

Hast Du mal auf allen Geräten ein "get ccconf" gemacht?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Rheingold am 20 Januar 2019, 22:39:32
Danke für den Link.
Nach etwas weiterem probieren habe ich festgestellt, dass folgender Eintrag dazu verholfen hat dass es wieder klappt:

attr MAPLECUL433 rfmode SlowRF

Jetzt läufts wieder :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 20 Januar 2019, 22:42:40
Dann ist ja gut :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 22 Januar 2019, 07:25:58
Moin, ich hab mir auch mal 2 STM32 zugelegt und wollte da jetzt den Bootloader flashen. Allerdings krieg ichs nicht hin.
Ich habe aktuell keinen "echten" USB-TTL Adapter, sondern einen Arduino Nano mit CH340. Bisher konnte ich damit jedoch alles flashen.
Laut stm32duino scheint es auch prinzipiell mit dem CH340 möglich zu sein, den Bootloader zu flashen.

Probiert habe ich es unter Windows (stm32flash, flash loader), Mac (stm32) und direkt am Pi (stm32). Allerdings bekomme ich immer "Failed to init device".
Rx und Tx sind schon gekreuzt.

Wenn ich den stm32 anstecke, blinkt er. Zum Flashen halte ich dann but32 und drücke reset. Nach ca. 2 Sek. lasse ich dann den but32 los und keine LED leuchtet mehr.
Brauche ich denn die Brücke von boot1 zu gnd?
Vielleicht gibt es ja irgendwo eine ausführlichere Anleitung zum Bootloader und a-culf flashen?!

Alternativ, wie würde ich denn mit dem ST-Link flashen? Geht das einfacher?
Gruß und danke.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 22 Januar 2019, 07:32:41
Schon mal ins Wiki geschaut?

https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 22 Januar 2019, 07:54:44
jap, klar.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 22 Januar 2019, 07:55:30
Zitat von: Maui am 22 Januar 2019, 07:25:58
Brauche ich denn die Brücke von boot1 zu gnd?

Dann sollte der Punkt auch klar sein.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 22 Januar 2019, 08:00:06
Naja, kommt drauf an, wo man guckt. https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md)  ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 22 Januar 2019, 08:02:08
Zitat von: Maui am 22 Januar 2019, 08:00:06
Naja, kommt drauf an, wo man guckt. https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/README.md)  ;)

Deswegen habe ich gerade aufs Wiki verwiesen. Mach ich ja nicht ohne Grund.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 22 Januar 2019, 08:39:45
Jungs Worldpiece ;-)

Hat schon mal jemand dies über USB probiert: Eine INO die den Bootloader intern ersetzt!?
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 22 Januar 2019, 08:41:57
Gute Idee. Das probiere ich mal morgen. Danke. Feedback folgt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 22 Januar 2019, 19:39:15
Zitat von: RaspiLED am 22 Januar 2019, 08:39:45
Jungs Worldpiece ;-)

Hat schon mal jemand dies über USB probiert: Eine INO die den Bootloader intern ersetzt!?
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader

Gruß Arnd


Gesendet von iPhone mit Tapatalk

Hat geklappt. Danke dir für den sinnvollen Tipp
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 22 Januar 2019, 20:00:33
Cool, schreibst Du das Wiki um?

Dann geht ja doch alles USB ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 23 Januar 2019, 07:46:21
Ich meine ich hab keinen Wiki Zugang.  :P
Leider habe ich bisher nur einen CUL, mein W5500 will noch nicht so wie ich.
-Lötstellen überprüft
-W5500 geflasht (nicht W5100)
-mit und ohne DHCP getestet
-LEDs leuchten beide (1 blinkt, 1 leuchtet)

Mit DHCP bekomme ich auch eine IP, allerdings im falschen Subnet. Bekomme 192.168.0.244, bin allerdings in 192.168.1.xx unterwegs.
Vielleicht ist auch bei mir das Ethernet Modul kaputt. Habe noch ein 2., welches ich wohl oder übel mal testen muss.
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 23 Januar 2019, 08:05:05
Moin,
dann schreibe doch mal die Anleitung hierhin, wir bekommen das schon ins Wiki ;-)
W/ DHCP hast Du denn zwei DHCP Server?
Kannst Du mit einem Rechner mit temporärer fester IP auf 192.168.0.111 im anderen Subnetz denn zugreifen?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 23 Januar 2019, 10:20:32
Okay, dann versuch ich mich mal:
Bootloader flashen ohne TTL-Adapter
Dies dürfte nur funktionieren, wenn der STM32 bereits mit einem Bootloader bestückt ist.
Die Schritte unter Installation müssen durchgeführt werden, damit der STM32 per Arduino IDE geflasht werden kann.
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation
Wichtig ist dabei auch, dass unter Windows die Treiber wie angegeben genommen werden. Mit Treibern aus Jadig geht es zb nicht. (Libusbk)

Geflasht wird dann die Ino von hier
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader#update-using-the-updater-sketch
Im Anschluss muss in der Arduino IDE der Serielle Monitor ausgeführt werden und dort einmal das flashen mit Y quittiert werden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 23 Januar 2019, 11:25:19
Ein funktionierender CUN lässt sich pingen, oder?
Würde für mich das debuggen einfacher machen, wenn ichs weiß :)
Und sollte der Befehl Ec beim mapleCUN funktionieren? Wäre in fhem unter get ...  raw Ec, richtig?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 23 Januar 2019, 12:06:37
Ping geht auf jeden Fall.

Es gab aber schon öfter Probleme mit dem W5500 Ethernet Modul. Bei mir hat das erste auch nicht funktioniert. Ein neues bestellt und das lief auf Anhieb. ,,

Du kannst aber auch einfach eine ältere Firmware flashen, dann kannst du den Debug Port für Debug Ausgaben nutzen und sehen ob das Ethernet Modul richtig funktioniert.
Hier siehst du wie es aussehen muss: https://forum.fhem.de/index.php/topic,60458.msg653838/topicseen.html#msg653838
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 23 Januar 2019, 15:57:40
Beim W5500 gibt es bei zu niederer Spannung immer Probleme.

Bei wenigen muss man die LAN Büchse nachlöten.
Ganz wenige haben nen Kurzschluss zwischen GND und VCC. Auch ganz wenige werden einfach nicht von der MAPLE Seite aus erkannt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 23 Januar 2019, 17:27:40
ZitatBekomme 192.168.0.244, bin allerdings in 192.168.1.xx unterwegs.

das ist aber ziemlich merkwürdig. Falls dein Router tcpdump kann:

tcpdump -i $INTERFACE_NAME -n -v -e 'ether host $MAC-Adresse-des-W5500'

Falls Du die MAC-Adresse nicht kennst - Direktverbindung mit dem W5500-Interface, booten und:

tcpdump -i $INTERFACE_NAME -n -v -e

Hier solltest Du Kommunikation (DHCP DISCOVER etc.) sehen. Das Ganze geht natürlich auch mit Wireshark auf deinem Standardsystem in Direktverbindung mit dem Modul.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 23 Januar 2019, 22:35:03
Zitat von: Ranseyer am 23 Januar 2019, 15:57:40
Beim W5500 gibt es bei zu niederer Spannung immer Probleme.

Bei wenigen muss man die LAN Büchse nachlöten.
Ganz wenige haben nen Kurzschluss zwischen GND und VCC. Auch ganz wenige werden einfach nicht von der MAPLE Seite aus erkannt.
Hab jetzt mal debug angelötet und alte Firmware drauf. Laut Log wird das Ethernet Modul nicht erkannt.
Hab auch schon einen 2. W5500 angelötet. Aber auch da alles gleich.
-Spannung ist 3.26V, so wie sie vom STM32 kommt.
-was meinst mit nachlöten? Einfach die Verbindungen von STM32 zu W5500 überprüfen?
-Kurzschluss könnte man ja mit Multimeter sehen

Ich hatte am Anfang den W5500 spiegelverkehrt angelötet und dadurch unter anderem einen Kurzschluss zwischen VCC und GND verursacht. Aber das legt ja auch den ganzen STM32 lahm. Evtl. Hat er dabei auch leicht einen weg gekriegt.
Ansonsten gehen mir grad die Ideen aus. Gibt es bessere Alternativen (die mit mapleCUN laufen) zum W5500?!
Scheint nicht so zuverlässig zu sein.

Ali müsste mal Prime einführen dann wäre alles einfacher  ;D

EDIT: Ich glaub auch nicht, dass ich zb falsch verdrahtet habe.

STM32->W5500
GND (39) -> GND
MOSI2 (28) -> MOSI
SCK2 (30) -> SCLK
WIZ CS (31) -> CS
VCC (40) -> VCC
WIZ RST (27) -> RST
MISO2 (29) -> MISO
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 26 Januar 2019, 21:56:27
Zitat-was meinst mit nachlöten? Einfach die Verbindungen von STM32 zu W5500 überprüfen?


Das betrifft dich nicht. Das wäre wenn Modul erkannt, aber keine Kommunikation in Richtung LAN Kabel funktioniert.


Btw: Ich habe mal massiv das Beispiel im Wiki editiert: https://wiki.fhem.de/wiki/MapleCUN#Einrichtung_in_FHEM_.28neu.29
Feedback ist willkommen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 26 Januar 2019, 23:41:59
Ich hab mir bei Ali nochmal paar Maple Mini und W5500 bestellt. Wenn die irgendwann da sind, dann teste ich erstmal aufm breadboard. Solange müssen es meine nanoCULs noch tun.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 27 Januar 2019, 23:14:02
Hm, mal eine Frage:

Ich hab ein 868 und ein 433 Modul auf meinem Maple. Das 433-Device funktioniert eigetnlich (also ich empfange Daten), aber wenn ich "get sys_cul433 ccconfig" aufrufe, dann komme ich nur:
Timeout reading answer for get C0D

Ist das normal, dass man auf dem Device keine normalen get-Befehle aufrufen kann (wegen Stackable evtl.?)?

Die Devices:
defmod sys_cul868 CUL /dev/serial/by-id/usb-STM32_MapleCUL_58eb37e5-if00@38400 1432
attr sys_cul868 alias CUL 868 MHz SlowRF
attr sys_cul868 group Schnittstellen
attr sys_cul868 rfmode SlowRF
attr sys_cul868 room System

setstate sys_cul868 2019-01-27 23:02:01 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
setstate sys_cul868 2019-01-27 23:05:04 cmds  B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
setstate sys_cul868 2019-01-27 23:11:22 state Initialized


defmod sys_cul868stack STACKABLE sys_cul868
attr sys_cul868stack alias CUL 868 MHz Stackable
attr sys_cul868stack group Schnittstellen
attr sys_cul868stack room System

setstate sys_cul868stack 0
setstate sys_cul868stack 2019-01-27 23:11:44 state 0


defmod sys_cul433 CUL FHEM:DEVIO:sys_cul868stack:9600 0000
attr sys_cul433 alias CUL 433 MHz SlowRF
attr sys_cul433 group Schnittstellen
attr sys_cul433 rfmode SlowRF
attr sys_cul433 room System

setstate sys_cul433 2019-01-27 21:04:10 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
setstate sys_cul433 2019-01-27 23:05:04 cmds  b C F i A Z N E G M K L U Y R T V W X f x z
setstate sys_cul433 2019-01-27 17:09:19 raw No answer
setstate sys_cul433 2019-01-27 23:12:05 state Initialized
setstate sys_cul433 2019-01-27 20:45:38 uptime No answer


EDIT:
Ich muss sagen, ich kapier eigentlich gar nicht, wie diese ganze Stackable-Sache technisch funktioniert...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: FunkOdyssey am 27 Januar 2019, 23:52:12
Ich habe genau das gleiche Problem:
https://forum.fhem.de/index.php/topic,80872.msg893193.html#msg893193
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 28 Januar 2019, 06:15:13
Hi,
ist eigentlich nicht normal.
Bekommst Du nie eine Antwort bei cccconf? Nirmal solltest Du 433.920 MHz auch angezeigt bekommen.

Diese Stackable Geschichte ist einfach!
Es werden für jeden Stack * vor den Befehl gestellt:
V -> Versionsabfrage Maple1
*V -> Versionsabfrage Maple2
**V -> Versionsabfrage Maple3
***V -> Versionsabfrage Maple4

Kannst Du mit raw auch testen ;-)

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 28 Januar 2019, 08:30:59
Ah danke, dann jetzt ist zumindest stackable soweit klar.

Also auf der Konsole per screen kann ich sauber mit beiden IOs reden:
? (r is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
*? (r is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f x z
? (v is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
V 1.26.05 a-culfw Build: private build (unknown) MapleCUNx4_03 (F-Band: 868MHz)
*V 1.26.05 a-culfw Build: private build (unknown) MapleCUNx4_03 (F-Band: 433MHz)
*omAAAAAAAB32D4CB3554D4D2AB554D52D55552B552D34D2AB43E
*i404115F9
V 1.26.05 a-culfw Build: private build (unknown) MapleCUNx4_03 (F-Band: 868MHz)
*omAAAAAAAB32D4CB3555352AB2D52D5535AA56A666A6A69A6520
*omAAAB32D4CB3555352AB2D52D553554AD4CCD4D4D34CA1F
*V 1.26.05 a-culfw Build: private build (unknown) MapleCUNx4_03 (F-Band: 433MHz)


Nur in FHEM klappt das nie mit meinem sys_cul433. Das ging aber damals schonmal (vor ca. 3 Wochen), nachdem ich es gerade frisch eingerichtet hatte.

Ich hab mal alle 3 Devices auf verbose5 gesetzt. Wenn ich bei dem cul433 "get ccconfig" mache, dann steht im Log nur:
2019.01.28 08:29:05.485 5 : SW: C0D
2019.01.28 08:29:08.490 1 : [Freezemon] sys_freezemon: possible freeze starting at 08:29:06, delay is 2.489 possibly caused by: no bad guy found :-(


Scheint schon ein Problem mit FHEM zu sein.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 28 Januar 2019, 09:04:29
Hi,
Interessant. Vorgestern habe ich gelesen, dass die get non-blocking und die set blocking sind. Aber was da bei Dir passiert solltest Du mal analysieren.
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 28 Januar 2019, 18:45:26
Glaube ich hab es:
Interessanterweise geht es immer für ein paar Sekunden nach dem Start von FHEM:
2019-01-28 18:34:14.166 CUL_HM wz_lightCrystal on
2019.01.28 18:34:14.960 3 : CUL_HM set wz_lightDesk statusRequest
2019.01.28 18:34:14.997 2 : DevIo_SimpleWrite C0D
2019.01.28 18:34:14.997 2 : DevIo_SimpleWrite *C0D
2019.01.28 18:34:15.001 2 : DevIo_SimpleWrite C0E
2019.01.28 18:34:15.001 2 : DevIo_SimpleWrite *C0E
2019.01.28 18:34:15.004 2 : DevIo_SimpleWrite C0F
2019.01.28 18:34:15.004 2 : DevIo_SimpleWrite *C0F
2019.01.28 18:34:15.007 2 : DevIo_SimpleWrite C10
2019.01.28 18:34:15.007 2 : DevIo_SimpleWrite *C10
2019.01.28 18:34:15.011 2 : DevIo_SimpleWrite C1B
2019.01.28 18:34:15.011 2 : DevIo_SimpleWrite *C1B
2019.01.28 18:34:15.015 2 : DevIo_SimpleWrite C1D
2019.01.28 18:34:15.015 2 : DevIo_SimpleWrite *C1D
2019-01-28 18:34:15.022 CUL sys_cul433 ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
2019-01-28 18:34:15.171 CUL_HM wz_lightDesk dim: stop:on
2019-01-28 18:34:15.171 CUL_HM wz_lightDesk pct: 100
2019-01-28 18:34:15.171 CUL_HM wz_lightDesk on
2019.01.28 18:34:15.965 3 : CUL_HM set wz_lightRed statusRequest
2019-01-28 18:34:16.182 CUL_HM wz_lightRed dim: stop:on
2019-01-28 18:34:16.182 CUL_HM wz_lightRed pct: 100
2019-01-28 18:34:16.182 CUL_HM wz_lightRed on
2019.01.28 18:34:16.970 3 : CUL_HM set wz_lightSpot statusRequest
2019.01.28 18:34:19.276 2 : DevIo_SimpleWrite C0D
2019.01.28 18:34:19.277 2 : DevIo_SimpleWrite *C0D
2019.01.28 18:34:19.280 2 : DevIo_SimpleWrite C0E
2019.01.28 18:34:19.280 2 : DevIo_SimpleWrite *C0E
2019.01.28 18:34:19.283 2 : DevIo_SimpleWrite C0F
2019.01.28 18:34:19.283 2 : DevIo_SimpleWrite *C0F
2019.01.28 18:34:19.286 2 : DevIo_SimpleWrite C10
2019.01.28 18:34:19.286 2 : DevIo_SimpleWrite *C10
2019.01.28 18:34:19.290 2 : DevIo_SimpleWrite C1B
2019.01.28 18:34:19.290 2 : DevIo_SimpleWrite *C1B
2019.01.28 18:34:19.293 2 : DevIo_SimpleWrite C1D
2019.01.28 18:34:19.293 2 : DevIo_SimpleWrite *C1D
2019-01-28 18:34:19.308 CUL sys_cul433 ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
2019-01-28 18:34:20.243 CUL_HM ku_fridge batVoltage: 2.60
2019-01-28 18:34:20.243 CUL_HM ku_fridge humidity: 55
2019-01-28 18:34:20.243 CUL_HM ku_fridge pressure: 977.4
2019-01-28 18:34:20.243 CUL_HM ku_fridge temperature: 6.5
2019.01.28 18:34:23.414 1 : PERL WARNING: Subroutine STACKABLE_IOOpenFn redefined at ./FHEM/16_STACKABLE_CC.pm line 175.
2019.01.28 18:34:23.414 1 : PERL WARNING: Subroutine STACKABLE_IOReadFn redefined at ./FHEM/16_STACKABLE_CC.pm line 185.
2019.01.28 18:34:23.414 1 : PERL WARNING: Subroutine STACKABLE_IOWriteFn redefined at ./FHEM/16_STACKABLE_CC.pm line 199.
2019-01-28 18:34:23.568 CUL_HM bd_virtTempWeather temperature: 20.1


Und dann kommt diese Meldung:
2019.01.28 18:34:23.414 1 : PERL WARNING: Subroutine STACKABLE_IOOpenFn redefined at ./FHEM/16_STACKABLE_CC.pm line 175.
2019.01.28 18:34:23.414 1 : PERL WARNING: Subroutine STACKABLE_IOReadFn redefined at ./FHEM/16_STACKABLE_CC.pm line 185.
2019.01.28 18:34:23.414 1 : PERL WARNING: Subroutine STACKABLE_IOWriteFn redefined at ./FHEM/16_STACKABLE_CC.pm line 199.

Und dann gehts nicht mehr.

Das Problem ist wohl, dass bei drei Funktionen innerhalb von 16_STACKABLE_CC das "CC" im Namen fehlt und die überschreiben dann die gleichnamigen Funktionen in 16_STACKABLE:
  $hash->{IOOpenFn}  = "STACKABLE_IOOpenFn";
  $hash->{IOReadFn}  = "STACKABLE_IOReadFn";
  $hash->{IOWriteFn} = "STACKABLE_IOWriteFn";


Wenn man die umbenennt, dann funktioniert es (unten im Code dann nochmal):
  $hash->{IOOpenFn}  = "STACKABLE_CC_IOOpenFn";
  $hash->{IOReadFn}  = "STACKABLE_CC_IOReadFn";
  $hash->{IOWriteFn} = "STACKABLE_CC_IOWriteFn";


Verstehe nur nicht, warum das nicht bei jedem auftritt?  ??? Evtl. Reihenfolge in der die Module geladen werden?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 Februar 2019, 15:54:17
Ich habe mal das CC2530-Addon produktiv in Betrieb genommen und dokumentiert im Wiki:
https://wiki.fhem.de/wiki/MapleCUX-Platinen#CC2530_AddOn
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dermitschi85 am 02 Februar 2019, 22:30:22
Hallo,

ich habe ein gebrauchtes MapleCUN Board ersteigert. Leider funktioniert es nicht. Eventuell kann mir jemand Schützenhilfe geben.

Es gibt folgendes Fehlerbild:

Ich habe zunächst den Bootloader neu geflasht, was ohne Weiteres nach ein paar Versuchen geglückt ist.
Leider kann ich das Teil nicht dazu bewegen in den DFU Modus zu wechseln um die aculfw zu flashen. Er scheint zwar drin zu sein, allerdings erkennt keines meiner Geräte den USB Port.

Ich gehe stark davon aus, dass irgend etwas auf der Platine nicht korrekt funktioniert. Unter Windows bekomme ich angezeigt, dass das Gerät nicht korrekt arbeitet. Unter Linux bekomme ich folgendes Fehlerbild siehe Bildschirmfoto.

Lötaugen wurden schon überprüft und nachgelötet aber dennoch keine Chance das Teil dazu zu bringen, per USB erkannt zu werden.

Evtl. hat jemand einen Hinweis um welches Bauteil es sich handeln könnte?

Außerdem ist mir, nach dem Studium des Platinenplans aufgefallen, dass auf F1 wohl eine Brücke anstatt einer Sicherung verbaut ist. Ist das normal? Oder kann das schon ein Fehler sein?


Ich wäre für jeden Hinweis dankbar!

Grüße Michi


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 02 Februar 2019, 22:33:58
Zitat von: dermitschi85 am 02 Februar 2019, 22:30:22
Hallo,

ich habe ein gebrauchtes MapleCUN Board ersteigert. Leider funktioniert es nicht. Eventuell kann mir jemand Schützenhilfe geben.

Es gibt folgendes Fehlerbild:

...

Versuch es doch mal bitte direkt im Nachbarthread, da geht es direkt um deine Platine: https://forum.fhem.de/index.php?topic=80872.0
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dermitschi85 am 02 Februar 2019, 22:36:11
Zitat von: gloob am 02 Februar 2019, 22:33:58
Versuch es doch mal bitte direkt im Nachbarthread, da geht es direkt um deine Platine: https://forum.fhem.de/index.php?topic=80872.0

Mach ich! Danke!

Gruß Michi
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 04 Februar 2019, 14:08:28
Ich hab das Problem, dass ich beim Empfang meiner 433MHz-Thermometer manchmal in sehr kurzer Zeit (<1 s) doppelte Readings habe.
Das sieht dann im Log so aus:
2019.02.04 14:02:50.051 5 : CUL/RAW: /*omAAAAAAAB32D4CB35554CCCD554D52CD55552B552CCB4B4CDFE
2019.02.04 14:02:50.052 4 : CUL_Parse: sys_cul868 *omAAAAAAAB32D4CB35554CCCD554D52CD55552B552CCB4B4CDFE
2019.02.04 14:02:50.052 5 : sys_cul868: dispatch *omAAAAAAAB32D4CB35554CCCD554D52CD55552B552CCB4B4CDFE
2019-02-04 14:02:50.065 OREGON ku_thgr228n temperature: 16.1
2019.02.04 14:02:50.292 5 : CUL/RAW: /*omACCB532CD5553333555354B355554AD54B32D2D330FC
2019.02.04 14:02:50.292 4 : CUL_Parse: sys_cul868 *omACCB532CD5553333555354B355554AD54B32D2D330FC
2019.02.04 14:02:50.293 5 : sys_cul868: dispatch *omACCB532CD5553333555354B355554AD54B32D2D330FC
2019-02-04 14:02:50.303 OREGON ku_thgr228n temperature: 16.1


Interpretiere ich das richtig, dass das kein Problem von FHEM bzw. CUL-Firmware ist, sondern die Thermometer offenbar tatsächlich innerhalb von 300 ms zweimal senden?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 04 Februar 2019, 17:05:23
Hallo Leute,

hat jemand für Antennen ein gute Bezugsquelle?
Also für 433Mhz und 868Mhz Antennen?

Irgendwie ist das wie ein Jungle.

Danke und Gruß Robert
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Februar 2019, 17:09:00
Ich verwende folgende Antennen und bin damit zufrieden:

https://de.aliexpress.com/item/2-piece-5-dbi-433Mhz-Free-Shipping-GSM-Antenna-SMA-Male-Connector-Rubber-Aerial-Wireless-Repeater/32806809309.html?spm=a2g0s.9042311.0.0.27424c4dqOOyaY
https://de.aliexpress.com/item/5-st-cke-868-MHz-915-MHz-Antenne-5dbi-SMA-Stecker-868-MHz-915-MHz-antena/32921480326.html?spm=a2g0s.9042311.0.0.27424c4dqOOyaY

Man sollte allerdings bedenken, dass sie etwas breiter sind an der Verschraubung und zum Beispiel nicht an den MapleCUN von Locutus passen.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: FunkOdyssey am 04 Februar 2019, 17:11:08
Es gibt hier im Forum einen Antennenthread. Mit diesen Infos habe ich folgende Antennen zum Ausprobieren bestellt:

https://de.aliexpress.com/item/2Pcs-Lot-Omni-868MHz-High-Gain-uhf-Antenna-CDSENET-TX868-JK-20-SMA-Male-868-MHz/32812387108.html?spm=a2g0s.9042311.0.0.12314c4dWmz6Zn

https://de.aliexpress.com/item/Free-shipping-868MHz-external-antenna-radio-receivers-antenna-SMA-Male-2pcs-Lot/32811231309.html?spm=a2g0s.9042311.0.0.12314c4dWmz6Zn
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 04 Februar 2019, 19:59:20
Zitat von: gloob am 04 Februar 2019, 17:09:00
Ich verwende folgende Antennen und bin damit zufrieden:

https://de.aliexpress.com/item/2-piece-5-dbi-433Mhz-Free-Shipping-GSM-Antenna-SMA-Male-Connector-Rubber-Aerial-Wireless-Repeater/32806809309.html?spm=a2g0s.9042311.0.0.27424c4dqOOyaY
https://de.aliexpress.com/item/5-st-cke-868-MHz-915-MHz-Antenne-5dbi-SMA-Stecker-868-MHz-915-MHz-antena/32921480326.html?spm=a2g0s.9042311.0.0.27424c4dqOOyaY

Man sollte allerdings bedenken, dass sie etwas breiter sind an der Verschraubung und zum Beispiel nicht an den MapleCUN von Locutus passen.

Danke, werde ich mal testen.

Gruß Robert
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 04 Februar 2019, 20:33:51
Hi,
Haben mir zu viel Richtwirkung, daher nutze ich diese: 

NiceRF stick antenna SW433-WT100 Rubber Antenna SMA Connector Elbow Rod Antenna 433mhz 3.0 dBi RF antenna

868mhz rubber Antenna SW868-WT100 Wireless Antenna 3.0 dBi rubber antenna 868mhz

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 04 Februar 2019, 20:35:59
Zitat von: RaspiLED am 04 Februar 2019, 20:33:51
Haben mir zu viel Richtwirkung, daher nutze ich diese: 

NiceRF stick antenna SW433-WT100 Rubber Antenna SMA Connector Elbow Rod Antenna 433mhz 3.0 dBi RF antenna
868mhz rubber Antenna SW868-WT100 Wireless Antenna 3.0 dBi rubber antenna 868mhz

Hast du bei den Antennen mal den Kunststoff abgezogen? Da kannst du auch gleich ein Stückchen Draht anlöten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 04 Februar 2019, 20:50:32
Hier mal jemand ein paar der Teile vermessen: https://forum.fhem.de/index.php/topic,93021.0.html

PS: Die Rundstrahler die oberhalb verlinkt wurden vermeiden lediglich "funken in die Erde und den Himmel" wenn man diese wie vorgesehen vertikal betreibt.

Das bedeutet:
A) 3dB Gewinn ist immer gelogen
B) Rundum gleichmäßige Abstrahlung wenn diese sauber verarbeitet sind
C) Falls der VSWR nicht passt eine Menge Verlust durch Reflexionen (Power die nicht abgestrahlt wird)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 06 Februar 2019, 21:00:44
@Telekatz
Mal eine Frage: welches ist denn momentan die "offizielle" bzw. empfohlene Firmware? Dein Repo ist ja zB. weiter als das von heliflieger.

Hier ist ja die Version von dir mit der IRQ-Steuerung:
https://forum.fhem.de/index.php/topic,60458.msg883138.html#msg883138

Hab ich jetzt aber z.B. keinen Commit zu gefunden. War das nur ein Test oder soll das übernommen werden?
https://github.com/Telekatz/a-culfw/tree/ARM
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Februar 2019, 09:36:08
Die empfohlene Firmware ist die von heliflieger.

Bei dem Test mit der IRQ-Steuerung bin ich noch nicht dazu gekommen, das zu übernehmen. Kommt aber noch.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 07 Februar 2019, 14:33:32
Ok, super, danke! Im Moment bin ich auf dieser Version hier, da der Fix für den UART für mich wichtig ist:
https://forum.fhem.de/index.php/topic,35064.msg868714.html#msg868714
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: FunkOdyssey am 12 Februar 2019, 14:22:55
Ich muss mal eine Frage stellen, die mich beschäftigt. Ich mich aber nie getraut habe, wirklich nachzufragen. :-)

Mein MapleCUL hat mein Signalduino abgelöst. Ich hatte relativ aktuelle Sketches von hhttps://github.com/Ralf9/SIGNALDuino/tree/dev-r332_cc1101 in Betrieb und habe unzählige 433Mhz-Geräte in meiner Umgebung gefunden. Dies ist beim MapleCUL aktuell nicht der Fall. Die vorhandenen IT-Geräte funktionieren natürlich, aber es wird nichts mehr automatisch gefunden.

Liegt das einfach daran, dass Signalduino sich einfach mehr "spezialisiert" hat oder habe ich einen Denkfehler?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 12 Februar 2019, 14:31:21
Zitat von: FunkOdyssey am 12 Februar 2019, 14:22:55
Ich muss mal eine Frage stellen, die mich beschäftigt. Ich mich aber nie getraut habe, wirklich nachzufragen. :-)

Mein MapleCUL hat mein Signalduino abgelöst. Ich hatte relativ aktuelle Sketches von hhttps://github.com/Ralf9/SIGNALDuino/tree/dev-r332_cc1101 in Betrieb und habe unzählige 433Mhz-Geräte in meiner Umgebung gefunden. Dies ist beim MapleCUL aktuell nicht der Fall. Die vorhandenen IT-Geräte funktionieren natürlich, aber es wird nichts mehr automatisch gefunden.

Liegt das einfach daran, dass Signalduino sich einfach mehr "spezialisiert" hat oder habe ich einen Denkfehler?

Wenn ich es richtig im Kopf habe arbeitet der Signalduino komplett anders als der CUL. Beim Signalduino wird das Signal nur erfasst und in FHEM ausgewertet. Beim CUL erfolgt die gesamte Auswertung im CUL selbst.
Der Signalduino unterstützt deutlich mehr Protokolle.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 15 Februar 2019, 06:04:25
Hallo Zusammen,

habe im Moment ein seltsames Problem mit einem Lacrosse Sensor (HMS) definiert auf Radio 1. Und zwar läuft er etwa 24 Stunden einwandfrei, dann überträgt er keine Daten mehr. Im log ist nichts zu finden über einen Verbindungsabbruch. Mache ich dann einen Reload auf Radio 1 läuft es wieder.
Hier mal en List des Devices:

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        192.168.178.30:2323 1234
   DeviceName 192.168.178.30:2323
   FD         32
   FHTID      1234
   FUUID      5c5e7eb3-f33f-f57d-2232-526ad57d3d2f66e7
   NAME       mCUL0_LaCrosse
   NR         281
   PARTIAL   
   RAWMSG     H430A00080241FF
   RSSI       -74.5
   STACKED    mCUL1_IT
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) MapleCUNx4_8F (F-Band: 868MHz)
   initString X21
   mCUL0_LaCrosse_MSGCNT 59187
   mCUL0_LaCrosse_TIME 2019-02-15 06:02:37
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     C:SD_WS07  ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-02-15 05:57:39   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2019-02-15 06:00:34   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2019-01-05 21:13:04   raw             0:115200
     2019-02-15 06:02:37   state           Initialized
     2019-01-05 21:04:44   uptime          0 12:40:20
     2019-01-05 09:13:12   version         V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) MapleCUNx4_87 (F-Band: 868MHz)
Attributes:
   DbLogExclude .*
   connectCommand Nr1
   model      CUN
   rfmode     SlowRF

Der Sensor ist schon ziemlich weit weg vom Maple, das lässt sich leider auch nicht ändern. Aber was mich stutzig macht, ist die Tatsache das es immer etwa 24 Stunden läuft.
Das einzige was ich im Log finde sind solche Einträge:

2019.02.15 05:56:34 3: mCUL0_LaCrosse: Unknown code N0192860529C7AAAA00002D541A, help me!
2019.02.15 05:56:42 3: mCUL0_LaCrosse: Unknown code N0192860529C7AAAA00000AC4C9, help me!
2019.02.15 05:56:50 3: mCUL0_LaCrosse: Unknown code N0192860529C7AAAA0000029B2C, help me!
2019.02.15 05:56:58 3: mCUL0_LaCrosse: Unknown code N0192860529C7AAAA00001543D5, help me!
2019.02.15 05:57:06 3: mCUL0_LaCrosse: Unknown code N0192860529C7AAAA00002206D6, help me!

Hier noch ein List des Sensors:

Internals:
   CODE       430a
   DEF        430a
   FUUID      5c5e7eb4-f33f-f57d-9942-3196f789d4cbc57d
   IODev      mCUL0_LaCrosse
   LASTInputDev mCUL0_LaCrosse
   MSGCNT     24719
   NAME       Temp_Zimmer
   NR         283
   STATE      T: 20.7  H: 41  Bat: ok
   TYPE       HMS
   mCUL0_LaCrosse_MSGCNT 24717
   mCUL0_LaCrosse_RAWMSG 810e04xx0510a001430a000000070241
   mCUL0_LaCrosse_RSSI -74.5
   mCUL0_LaCrosse_TIME 2019-02-15 06:01:15
   mCUL1_IT_MSGCNT 2
   mCUL1_IT_RAWMSG 810e04xx0510a001430a000000070241
   mCUL1_IT_RSSI -74.5
   mCUL1_IT_TIME 2019-02-15 06:00:34
   Helper:
     DBLOG:
       data:
         logdb:
           TIME       1550206498.06537
           VALUE      state: T: 20.4  H: 41  Bat: ok
   READINGS:
     2019-02-15 06:01:15   battery         ok
     2019-02-15 06:01:15   batteryState    ok
     2019-02-15 06:01:15   humidity        41
     2019-02-15 06:01:15   state           T: 20.7  H: 41  Bat: ok
     2019-02-15 06:01:15   temperature     20.7
     2019-02-15 06:01:15   type            HMS100TF
Attributes:
   IODev      mCUL0_LaCrosse
   room       HMS




Wäre klasse wenn jemand eine Idee hätte wie ich das in den Griff bekommen könnte und ob es tatsächlich an der Entfernung zwischen Maple und Sensor liegen kann.

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 15 Februar 2019, 11:21:06
Hi Markus,

evtl. locke ich dich jetzt auf eine falsche Fährte, aber ich hatte mit einem HM-Modul am UART mal ein ähnliches Problem (immer auch nach ca. 24h keine Kommuninkation mehr). Da lag es daran, dass die Firmware da nicht ganz rund war und irgendwann keine Daten mehr geliefert hat. Eigentlich denke ich aber nicht, dass genau das in deinem Fall auch passieren kann.

Trotzdem: eh wir jetzt lange spekulieren, könntest du einfach mal die Firmware von hier ausprobieren: https://forum.fhem.de/index.php/topic,35064.msg868714.html#msg868714

Wenn es wider Erwarten doch helfen sollte, dann können wir uns immer noch überlegen warum ;)

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 15 Februar 2019, 17:48:41
Kurzes Update zu meinem Problem mit LAN.
Schien wohl mein STM32 gewesen zu sein.
Der neue läuft jetzt problemlos.
Konnte auch wieder problemlos den Bootloader per sketch hochladen.
Nur DHCP geht nicht (scheint aber typisch für Gigabit LAN zu sein)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 15 Februar 2019, 17:52:28
Zitat von: vbs am 15 Februar 2019, 11:21:06
Hi Markus,

evtl. locke ich dich jetzt auf eine falsche Fährte, aber ich hatte mit einem HM-Modul am UART mal ein ähnliches Problem (immer auch nach ca. 24h keine Kommuninkation mehr). Da lag es daran, dass die Firmware da nicht ganz rund war und irgendwann keine Daten mehr geliefert hat. Eigentlich denke ich aber nicht, dass genau das in deinem Fall auch passieren kann.

Trotzdem: eh wir jetzt lange spekulieren, könntest du einfach mal die Firmware von hier ausprobieren: https://forum.fhem.de/index.php/topic,35064.msg868714.html#msg868714

Wenn es wider Erwarten doch helfen sollte, dann können wir uns immer noch überlegen warum ;)

Glaube werde mal die andere FW probieren. Kann man die eigentlich einfach "drüber bügeln" oder muss man den Maple vorher "blanken"...?
Und läuft die 5100BL auch auf dem 5500?
Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Februar 2019, 18:40:07
Firmware einfach über den USB-Bootloader drüberspielen. Die für das jeweils andere Netzwerkmodul kann bestimmt auch nehmen. Dann funktioniert aber kein Netz mehr.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 15 Februar 2019, 19:06:06
Super dann kann ich das wohl vergessen. Brauche den LAN Anschluß :-(

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 15 Februar 2019, 19:15:35
Kann dir so eine Firmware kompilieren, denk ich! Also du brauchst die 5500?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 15 Februar 2019, 19:23:30
Juhuuuu ja bitte :-) genau die 5500..

Viiiiiiiilen Dank

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 15 Februar 2019, 19:30:02
Gerne doch.

Ist jetzt die Version 1.26.05 aus dem Commit:
https://github.com/heliflieger/a-culfw/commit/0a7040de3f3d8b2de9d42576024646221d9f3165

Wie gesagt, ich will nicht behaupten, dass die Chancen gut sind, dass es bei dir hilft, aber probieren kann nicht schaden, denk ich.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 15 Februar 2019, 19:37:07
Zitat von: vbs am 15 Februar 2019, 19:30:02
Gerne doch.

Ist jetzt die Version 1.26.05 aus dem Commit:
https://github.com/heliflieger/a-culfw/commit/0a7040de3f3d8b2de9d42576024646221d9f3165

Wie gesagt, ich will nicht behaupten, dass die Chancen gut sind, dass es bei dir hilft, aber probieren kann nicht schaden, denk ich.

Klasse danke dir werde ich am we testen und Bescheid geben. Und da sind die Änderungen aus dem anderen Post drin?

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 15 Februar 2019, 20:03:54
Genau, das ist dieser Commit und der ist drin:
https://github.com/heliflieger/a-culfw/commit/6f3f6b896916d3f9b9221c333f9073b9381cac6a
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 16 Februar 2019, 07:35:59
so Firmware mal geflasht, raw e gemacht.
Jetzt bin ich mal gespannt :-)

Vielen Dank nochmal !!

Viele Grüße

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 18 Februar 2019, 13:32:44
Ich muss nochmal stören  ::)
Jetzt läuft zwar mein CUN, also das LAN, aber ich kann meine MAX Geräte nicht wirklich pairen.
Habe Fensterkontakte und Thermostate.
Die Fensterkontakte kann ich pairen, die Thermostate allerdings nicht.
Ich hab aktuell 2 nanoCULs, bei denen es problemlos läuft.
Mit dem mapleCUN krieg ich es aber irgendwie nicht hin.
Habe schon im Debug geschaut, CC wird erkannt.
FK kann ich ja wie gesagt auch pairen.
Habe trotzdem mal einen CC1101 vom nanoCUL genommen, aber auch da keine Besserung.
Auf den nanoCULs läuft culfw statt a-culfw.

Vielleicht hat ja einer von euch eine Idee, auch wenn es vielleicht eher ein CUL oder MAX-Problem ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 18 Februar 2019, 13:39:17
Thermostate resetet bevor du sie anlernen wolltest?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 18 Februar 2019, 13:41:22
Klar, sauber resettet. Und auch dann wieder am nanoCUL getestet. Ging ohne Probleme, AC kommt sofort.
Aber am mapleCUN kommt einfach kein AC und das Device wird nicht angelegt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 18 Februar 2019, 14:15:15
AES eingeschaltet?
Schlüssel hinterlegt?
Warum neu anlernen? VCCU?

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 18 Februar 2019, 14:19:36
Zitat von: RaspiLED am 18 Februar 2019, 14:15:15
AES eingeschaltet?
Schlüssel hinterlegt?
Warum neu anlernen? VCCU?

Gruß Arnd


Gesendet von iPhone mit Tapatalk

Auch wenn ich mich vielleicht als dumm oute:
-Dachte MAX hat kein AES?
-Schlüssel?
-VCCU geht nur bei HM?!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 18 Februar 2019, 18:32:11
Sorry war im falschen Film *duck weg*
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 19 Februar 2019, 08:01:33
Zitat von: Markus. am 16 Februar 2019, 07:35:59
so Firmware mal geflasht, raw e gemacht.
Jetzt bin ich mal gespannt :-)

Vielen Dank nochmal !!

Viele Grüße

Markus

Hallo Zusammen,

wollte ja mal Rückmeldung geben bezüglich des Problems mit dem Lacrosse Sensor und dessen Phänomen, das er nach ca. 24 Stunden keine Daten mehr bekommt..
Also das Problem ist mit der modifizierten Firmware genauso. Ich werde jetzt mal die Spannungsversorgung wechsel und eventuell versuchen den Maple näher an den Sensor zu bekommen. Bezüglich der Spannungsversorgung verwende ich zur Zeit ein 5V Netzteil über den Buchsenstecker. Vielleicht liegt ja da was im argen...

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 19 Februar 2019, 08:38:11
Zitat von: Markus. am 19 Februar 2019, 08:01:33
Hallo Zusammen,

wollte ja mal Rückmeldung geben bezüglich des Problems mit dem Lacrosse Sensor und dessen Phänomen, das er nach ca. 24 Stunden keine Daten mehr bekommt..
Also das Problem ist mit der modifizierten Firmware genauso. Ich werde jetzt mal die Spannungsversorgung wechsel und eventuell versuchen den Maple näher an den Sensor zu bekommen. Bezüglich der Spannungsversorgung verwende ich zur Zeit ein 5V Netzteil über den Buchsenstecker. Vielleicht liegt ja da was im argen...

Gruß

Markus

Wenn die Entfernung ein Problem ist, dann dürftest du aber sporadisch immer mal wieder Problem bekommen, und nicht erst nach 24 Std. Spannung sollte auch von vornherein Probleme machen.
Wenn der RSSI von -75 stimmt, dann sieht der doch nicht schlecht aus.
Ab -80 bzw. -85 bekomme ich persönlich Probleme mit ACK.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 19 Februar 2019, 08:46:49
Habe mein HK-Thermostat angelernt bekommen, nur fragt mich nicht wie. (update, model, eigene Dummheit :P )
Aber direkt das nächste Problemchen. Habe aktuell 2 nanoCULs an 2 Pi's hängen wg. Reichweite (großes Haus). Beide funken nur auf MAX.
Mein Ziel war jetzt 2 mapleCUNs als Alternative zu nehmen. Und beide in 1 FHEM Instanz anzubinden.
Hat einer von euch sowas mit MAX erfolgreich am Laufen? Gestern in meinem Test hat mein maple meinem nano (Gott weiß warum) die ganzen Credits geklaut.
Erst ein delete und restart hat geholfen. Meine hier im Forum mal was von einer Unverträglichkeit mehrerer CUL_MAX in einer Instanz gelesen zu haben.

Eine Alternative wäre wohl mehrere FHEM Instanzen auf dem Pi (zb mit Docker) aufzumachen. Aber vielleicht ist das ja auch nich nötig.

EDIT: Hier wurde das Thema schon mal diskutiert. https://forum.fhem.de/index.php/topic,50076.msg418286.html#msg418286 (https://forum.fhem.de/index.php/topic,50076.msg418286.html#msg418286)
Ich werde jetzt pro CUL_MAX eine Instanz aufmachen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dkreutz am 19 Februar 2019, 09:20:38
Zitat von: Maui am 19 Februar 2019, 08:38:11
Wenn der RSSI von -75 stimmt, dann sieht der doch nicht schlecht aus.
Der RSSI stimmt nicht wirklich, bei mir wird auf ingesamt 10 HMS-Devices (HMS=LaCrosse), die am MapleCUL hängen ein RSSI von -74.5 angezeigt.
Das ist ein Bug in der Firmware bzw. hart codiert, dazu wurde hier im Thread/Forum mal was geschrieben...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 19 Februar 2019, 09:59:41
Hi,
ich hatte folgendes verstanden:
1) Ein LaCrosse wird nicht mehr in FHEM aktualisiert - andere schon
2) Nach 24h ist das definitiv der Fall
3) Dennoch sind Unknown Code N01... Einträge im Log, vermutlich von dem LaCrosse Sender
4) Der Sender ist okay, dann nach reopen des Maple kommen die Daten wieder richtig verarbeitet an

Sollte dies oben alles richtig verstanden sein, dann brauchst Du keine andere Stromversorgung probieren, sondern Telekatz (oder wer kennt sich noch in den Tiefen der a-culfw für LaCrosse aus?) könnte mal nach Timerproblemen oder Überläufen schauen.

Just my 2 cents ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 19 Februar 2019, 10:08:55
Zitat von: RaspiLED am 19 Februar 2019, 09:59:41
Hi,
ich hatte folgendes verstanden:
1) Ein LaCrosse wird nicht mehr in FHEM aktualisiert - andere schon
2) Nach 24h ist das definitiv der Fall
3) Dennoch sind Unknown Code N01... Einträge im Log, vermutlich von dem LaCrosse Sender
4) Der Sender ist okay, dann nach reopen des Maple kommen die Daten wieder richtig verarbeitet an

Sollte dies oben alles richtig verstanden sein, dann brauchst Du keine andere Stromversorgung probieren, sondern Telekatz (oder wer kennt sich noch in den Tiefen der a-culfw für LaCrosse aus?) könnte mal nach Timerproblemen oder Überläufen schauen.

Just my 2 cents ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk

Genau so ist es.... :-)
Das komische ist halt, das wenn die Daten nicht mehr aktualisiert werden von dem Lacrosse Device(so nach ca. 24Stunden), nach ein paar Stunden warten manchmal wieder Daten rein kommen. Re-open behebt das Problem sofort. Die N01-Einträge sind weiterhin vorhanden.

Gruß

markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 23 Februar 2019, 08:30:54
scheint wirlich ein "Timing-Problem" zu sein. Habe jetzt mal eine andere Spannungsvesorgung versucht und zudem den Sensor ganz nah an den Maple gebracht, auch eine andere Antenne habe ich mal getestet.
Aber das Phänomen bleibt...
Sensor läuft einwandfrei für ca. 24 Stunden, dann keine Datenaktualisierung mehr, reopen Maple und läuft wieder...
Hab den Maple auch mal umdefiniert, d.H. Lacrosse/HMS auf dem Radio definiert wo MAX einwandfrei klappt. Aber der Fehler wandert, also kann ich ein Hardware-Problem ausschließen.

Einer eine Idee?

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 23 Februar 2019, 08:45:48
Hmm hast du mal über die Holzhammer Methode nachgedacht?
Alle 12 Std. Per at oder DOIF ein reopen zu machen?
Nicht schön aber dürfte ja nicht viele side effects haben?!
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 23 Februar 2019, 08:56:31
könnte ich, will aber dem eigentlichen Problem auf die Spur kommen oder es zumindest verstehen. ;-)

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 23 Februar 2019, 19:00:40
Hi,
schau in der Firmware nach was da passiert.
Evtl. Ein paar Debugausgaben und schauen wo es crasht.
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 23 Februar 2019, 21:56:04
Hallo zusammen,

Ich habe heute unerwartet meine w5500 geliefert bekommen.

Nun wollte ich die w5500 gerade verlöten und habe bemerkt dass auf der Platine w5500 lite aufgedruckt ist.

Bin jetzt nicht sicher ob es die richtigen Module sind.

Kann mich hier ein bitte zu aufklären?

Danke und Gruß Robert


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 23 Februar 2019, 22:50:00
Keine Angst, auf meinem steht auch "lite" und der läuft ohne Probleme.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 24 Februar 2019, 08:59:33
Zitat von: gloob am 23 Februar 2019, 22:50:00
Keine Angst, auf meinem steht auch "lite" und der läuft ohne Probleme.

Danke dir.

Hat das mit dem Lite vll nur was mit der Größe zutun?
Achja hast du das Teil auf einem Sockel oder direkt verlötet?

Gruß Robert
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 24 Februar 2019, 09:01:20
Ich habe einen MapleCUN mit Sockel, dort teste ich die Module immer bevor ich sie fest auflöte.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 24 Februar 2019, 09:33:17
Ich würde dir auch vorher ein Testen empfehlen. Gefühlt scheinen nur 50% der LAN-Module auf Anhieb zu Gehen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 24 Februar 2019, 10:40:56
Zitat von: gloob am 24 Februar 2019, 09:01:20
Ich habe einen MapleCUN mit Sockel, dort teste ich die Module immer bevor ich sie fest auflöte.
Zitat von: Maui am 24 Februar 2019, 09:33:17
Ich würde dir auch vorher ein Testen empfehlen. Gefühlt scheinen nur 50% der LAN-Module auf Anhieb zu Gehen.
Danke für die schnelle Antwort.
Ich muss sagen auf den Sockeln sieht das ja echt scheiße aus!  :D
Werde dann aber beide mit Sockeln ausstatten, sicher ist sicher.

Gruß Robert
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 24 Februar 2019, 11:03:17
Es reicht doch wenn du eins mit Sockel hast, dort kannst du die Module testen und dann fest auf den 2. auflöten.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 24 Februar 2019, 11:19:42
Zitat von: gloob am 24 Februar 2019, 11:03:17
Es reicht doch wenn du eins mit Sockel hast, dort kannst du die Module testen und dann fest auf den 2. auflöten.

Auch wieder wahr.
Ich bin nur jemand der es gerne gleich hat.

Dazu wie testet ihr genau die Module?
Einfach ob die IP Verbindung (DHCP IP bekommen) geht oder macht ihr noch weiter tests?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 24 Februar 2019, 12:23:51
Wenn per DHCP eine IP Adresse vergeben wurde ist alles gut.

ZitatIch muss sagen auf den Sockeln sieht das ja echt scheiße aus!  :D
Werde dann aber beide mit Sockeln ausstatten, sicher ist sicher.
Ohne Test und ohne Entlötstation direkt auflöten ist sehr riskant geworden.

Aber das produktive LAN-Modul sockeln würde ich auf gar keinen Fall machen!
-So ein LAN-Kabel kann schon ordentlich Kraft übertragen.


Über was ich mal nachdenken könnte wäre ein modifizierter Footprint für das LAN Modul.
Also ca. so wie hier rechts neben C5: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Archiv/V3.5/top.png

Evtl. spannt das genug um das Modul zu testen. Nachteil: Ich habe natürlich einen kleinen MAPLE-CUL genau um das zu testen mit Sockel. Ich brauch das selber nicht, und auch ohne versetzte Pins ist das LAN Modul manchmal nur schwer montierbar. Je nach Tagesform des Herstellers...

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 24 Februar 2019, 12:30:03
Zitat von: Ranseyer am 24 Februar 2019, 12:23:51
Wenn per DHCP eine IP Adresse vergeben wurde ist alles gut.
Ohne Test und ohne Entlötstation direkt auflöten ist sehr riskant geworden.

Aber das produktive LAN-Modul sockeln würde ich auf gar keinen Fall machen!
-So ein LAN-Kabel kann schon ordentlich Kraft übertragen.


Über was ich mal nachdenken könnte wäre ein modifizierter Footprint für das LAN Modul.
Also ca. so wie hier rechts neben C5: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Archiv/V3.5/top.png

Evtl. spannt das genug um das Modul zu testen. Nachteil: Ich habe natürlich einen kleinen MAPLE-CUL genau um das zu testen mit Sockel. Ich brauch das selber nicht, und auch ohne versetzte Pins ist das LAN Modul manchmal nur schwer montierbar. Je nach Tagesform des Herstellers...

Anderer Gefragt, was muss man ein Testen bei einem W5500 Modul?
Einfach nur 5V und GND dran, danach im Router schauen ob eine IP Adresse bezogen wurde?
Oder muss man dazu schon ein wenig mehr machen?
Den einen hab eich nun gesockelt.
Da lässt sich auch nichts mehr ändern, habe keine Entlötstation nur eine Handlötpumpe.


Wenn man mehr machen müsste, könnte man das ganze nicht per Arduino in klein Simulieren.
MIt kurzen Jumperkabeln ist auf nem Breadboard immer schnell was zusammen gesteckt.

Gruß Robert
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 24 Februar 2019, 12:48:09
Probier doch mal ob der ohne intialisierung eine IP-Adresse holt... (Glaub ich nicht)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 24 Februar 2019, 13:41:18
Zum Glück hab ich einfach nicht Blind aufgelötet.
Ein Modul ist wirklich defekt.
Das hätte sogar ein blinder sehen müssen.
Hinten an der RJ45 Buchse sind die Pins teilweise kurzgeschlossen. Die RJ45 Buchse ist einfach nicht richtig ausgerichtet.

Ich hab im Internet folgenden Code Schnipsel für Arduino gefunden.
https://github.com/adafruit/Ethernet2/blob/master/examples/DhcpAddressPrinter/DhcpAddressPrinter.ino

Testen kann ich Ihn momentan leider nicht, mir fehlt die Zeit dafür

Gruß Robert
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 25 Februar 2019, 16:01:05
Zitat von: no_Legend am 24 Februar 2019, 13:41:18
Zum Glück hab ich einfach nicht Blind aufgelötet.
Ein Modul ist wirklich defekt.
Das hätte sogar ein blinder sehen müssen.
Hinten an der RJ45 Buchse sind die Pins teilweise kurzgeschlossen. Die RJ45 Buchse ist einfach nicht richtig ausgerichtet.
Hatte letztens auch W5500 Module bekommen wo die Kontakte der Netzwerkbuchse hinten nicht aufgelötet waren. manche hatten halt durch Zufall Kontakt und manche nicht. fehlte einfach Lötzinn.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 26 Februar 2019, 21:52:27
Zitat von: Markus. am 19 Februar 2019, 10:08:55
Genau so ist es.... :-)
Das komische ist halt, das wenn die Daten nicht mehr aktualisiert werden von dem Lacrosse Device(so nach ca. 24Stunden), nach ein paar Stunden warten manchmal wieder Daten rein kommen. Re-open behebt das Problem sofort. Die N01-Einträge sind weiterhin vorhanden.

Gruß

markus

Hallo Zusammen,

Habe mal bezüglich dieses Problems weiter ,,geforscht" und als erstes mal die Spannungsversorgung wieder üner USB anstatt über Buchse gemacht. Komischerweise läuft es nun seit drei Tagen ohne Probleme oder Ausfälle. Kann denn die Umzerschiedliche Art der Stromverorgung einen Unterschied machen in Bezug auf irgendwelche Timingprobleme bei Verwendung der Protokolle in dieser Konstellation? Probleme machte ja nur LaCrosse auf Radio 0 was nach 24 stunden zickte bei Versorgung über Buchse. Anderes Netzteil an der Buchse hatte ich schon getestet aber da war das selbe Problem. Nun läuft das selbe Netzteil für die Versorgung über Usb. Ich lass das noch ein paar Tage laufen umd steck dann nochmal um. Bin mal gespannt ob es dann wieder nach 24 Stunden zickt.

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 26 Februar 2019, 22:49:00
ZitatSpannungsversorgung wieder üner USB anstatt über Buchse gemacht. Komischerweise läuft es nun seit drei Tagen ohne Probleme oder Ausfälle

Zufall ?
(+Wenn du über einen Spannungsregler (+Buchse) einspeist, dann lieber 6V Netzteil nehmen...)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 27 Februar 2019, 07:31:20
Da ist kein Spannungsregler verbaut, lediglich die Brücke "no regulator"  geschlossen und eine Sicherung drin. Netzteil hat 2,5 A bei 5,3 V.

Gruß
Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 27 Februar 2019, 08:14:06
ZitatDa ist kein Spannungsregler verbaut,
OK, dann ist die Spannungsversorgung besser als per USB. Somit würde ich tippen dass die höhere "Stabilität" Zufall ist. ((?))

VIN und USB5V gehen beide über eine Diode auf den Spannungsregler des Maple:
https://wiki.stm32duino.com/images/2/26/Maple_mini_clone_schematic.JPG

Falls also deine MAPLE-CUL Platine einen fetten Kondensator hat, sollte Spannungsmäßig alles gut sein.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 27 Februar 2019, 19:47:26
Zitat von: Ranseyer am 27 Februar 2019, 08:14:06
OK, dann ist die Spannungsversorgung besser als per USB. Somit würde ich tippen dass die höhere "Stabilität" Zufall ist. ((?))

VIN und USB5V gehen beide über eine Diode auf den Spannungsregler des Maple:
https://wiki.stm32duino.com/images/2/26/Maple_mini_clone_schematic.JPG

Falls also deine MAPLE-CUL Platine einen fetten Kondensator hat, sollte Spannungsmäßig alles gut sein.

330uF sind drauf. An einen Zufall glaube.ich eher nicht. Muss mal sehen das ich logs mache.

Gruß
Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 28 Februar 2019, 14:25:03
Meine Erfahrung zeigt das ein USB Netzteil mit 5V und 500mA locker ausreicht (MapleCUN bestückt wie auf meiner Homepage). Man muss darauf achten das man kein USB Netzteil mit Schnelladefunktion verwendet. Auch Apple USB Adapter beispielsweise von einem iPhone oder iPad funktionieren nicht. Das Problem hierbei ist das diese Netzteile keinen Strom liefern solang nicht ein Chip dem Netzteil mitteilt wie viel Strom es liefern soll. Einen solchen Chip hat der Maple mini aber nicht. Ich verwende einen 220µF Kondensator (Elko) als Puffer auf meinen Leiterplatten.

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 28 Februar 2019, 15:17:05
ZitatAuch Apple USB Adapter beispielsweise von einem iPhone oder iPad funktionieren nicht. Das Problem hierbei ist das diese Netzteile keinen Strom liefern solang nicht ein Chip dem Netzteil mitteilt wie viel Strom es liefern soll.

Ganz so global stimmt das aber glaube ich nicht. Ich habe einen "vollbestückten" MapleCUN + Erweiterungsplatine inkl. CC2530 im Einsatz mit einem Apple MC359ZM/A iPad 10W. Geht wunderbar.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 28 Februar 2019, 15:19:07
Hatte einen Kunden mit einem iPad Netzteil. Das funktionierte nicht am MapleCUN er hat es gegen ein anderes getauscht und schon waren die Probleme weg. Welcher Typ das genau war kann ich leider nicht sagen. Handyladergeräte von Anker machten bei einem anderen Kunden Probleme.

Bei einem Kunden resetet sich der MapleCUN immer direkt wenn er sich per Netzwerk verbunden hat. Bei dem anderen resetet sich der MapleCUN sobald er etwas mit einem CC1101 senden wollte.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 28 Februar 2019, 15:21:10
ZitatWelcher Typ das genau war kann ich leider nicht sagen

Ggf. ein neueres Modell. Die Erfahrungswerte sind ja grundsätzlich auch richtig zu nennen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 28 Februar 2019, 15:30:39
Ich kann sicher sagen dass z. B. 4,7V am Eingang zu wenig sind mit LAN Modul...

Alles andere ist individuell..
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: no_Legend am 02 März 2019, 16:31:04
Hallo Leute,

ich hab heute mal einen meiner Zwei MaplesCuns in betrieb genommen.

Dazu mal eine Frage werden in FHEM keine RSSI Werte angezeigt?

Danke und Gruß Robert
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 02 März 2019, 20:56:10
ZitatDazu mal eine Frage werden in FHEM keine RSSI Werte angezeigt?

Doch schon: es unterscheidet sich aber hinsichtlich des eingesetzten Funkmoduls bzw. der darauf laufendem Softwareimplementierung / rfmode. Bei SlowRF / HMS habe ich statisch 74.5 - bei anderen bspw. HomeMatic werden realistische Werte angezeigt.

Setze mal auf die Module das Attribut addvaltrigger auf "1".
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 09:32:38
Hi,

ich habe einen MapleCUN mit folgender Konfiguration im Einsatz:

SW: V 1.26.05 a-culfw Build: 311

HW:

W5500 Ethernet
Modul1: freq:868.300MHz
Modul2: freq:433.920MHz
Modul3: freq:868.300MHz
Modul4: freq:868.300MHz
(HM-MOD-RPI über UART)
(CC2530 über UART)

Ich würde gerne meinen Z-Wave Verkehr sniffen - bestenfalls auf 9600, 40000 und 100000 bit/sec mittels ZWCUL & STACKABLE_CC.

Bevor ich da abtauche und verzweifle: Hat das jemand schon erfolgreich gemacht?

Danke :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 03 März 2019, 10:09:27
Da solltest du aharrenberg fragen... (Oder das Forum nach Posts von ihm zu Z-Wave durchsuchen)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 10:27:55
Danke für den Hinweis. Das habe ich bereits heute morgen gemacht und es ist ohne Zweifel die beste Basis die ich bisher gefunden habe.

U.a. hier in dem Thread:

https://forum.fhem.de/index.php/topic,68811.0.html

Und hier:

https://forum.fhem.de/index.php?topic=44905.210

Ich versuche es mal damit :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 10:34:29
Eine Frage noch: ich habe zwei FHEM Systeme die beide auf den MapleCUN zugreifen können. Telekatz hat das die Firmware so entwickelt, dass immer nur ein Socket (:2323) zum CUN geöffnet werden kann. Gibt es eine komfortable Methode wie ich zwischen den beiden hin und her switchen kann? Bspw. ein "deactivate" oder "ignore" Attribut? Bisher ändere ich immer die IP-Adresse bei einem der FHEM-Instanzen um sie ins leere laufen zu lassen (nicht optimal).
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 03 März 2019, 10:51:34
ZitatTelekatz hat das die Firmware so entwickelt, dass immer nur ein Socket (:2323) zum CUN geöffnet werden kann.
Für mich ein Sicherheitsfeature. Solange FHEM den CUL kontrolliert tut es kein anderer...  :o

((...ein "disabled" Attribut dazu kenne ich leider nicht...))
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 03 März 2019, 10:52:54
Zitat von: dmq am 03 März 2019, 10:34:29
Eine Frage noch: ich habe zwei FHEM Systeme die beide auf den MapleCUN zugreifen können. Telekatz hat das die Firmware so entwickelt, dass immer nur ein Socket (:2323) zum CUN geöffnet werden kann. Gibt es eine komfortable Methode wie ich zwischen den beiden hin und her switchen kann? Bspw. ein "deactivate" oder "ignore" Attribut? Bisher ändere ich immer die IP-Adresse bei einem der FHEM-Instanzen um sie ins leere laufen zu lassen (nicht optimal).

Einfach einen 2. MapleCUN bauen/besorgen/kaufen :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 10:54:54
ZitatEinfach einen 2. MapleCUN bauen/besorgen/kaufen

;D Ich hatte mir gedacht das jemand diese Antwort bringt. Da ist was dran  ;D
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 10:56:09
ZitatFür mich ein Sicherheitsfeature. Solange FHEM den CUL kontrolliert tut es kein anderer...

Ja, so sehe ich es auch. Bzw. könnte es ja ggf. auch negative Effekte haben, mit mehreren Instanzen auf den einen CUN zuzugreifen.

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 11:22:41
Ich bekomme die Referenzierung nicht hin:

define gateway_maplecun_00 CUL X.X.X.X:2323 NNNN
attr gateway_maplecun_00 addvaltrigger 1
attr gateway_maplecun_00 connectCommand Nr1
attr gateway_maplecun_00 rfmode SlowRF
attr gateway_maplecun_00 room Bridges
attr gateway_maplecun_00 verbose 2

define gateway_maplecun_zwave100k STACKABLE gateway_maplecun_00
define z100k ZWCUL FHEM:DEVIO:gateway_maplecun_zwave100k:9600 00000000 01
attr z100k dataRate 100k
attr z100k room Bridges
attr z100k verbose 5

define gateway_maplecun_zwave40k STACKABLE z100k
define z40k ZWCUL FHEM:DEVIO:gateway_maplecun_zwave40k:9600 00000000 01
attr z40k dataRate 40k
attr z40k room Bridges
attr z40k verbose 5

define gateway_maplecun_zwave9600 STACKABLE z40k
define z9.6 ZWCUL FHEM:DEVIO:gateway_maplecun_zwave9600:9600 00000000 01
attr z9.6 dataRate 9600
attr z9.6 room Bridges
attr z9.6 verbose 5



Die einzelnen Geräte z100k, z40k und z9.6 sind opened. Es wird aber nichts angezeigt.

Das erste Modul liefert noch freundlich Lacrosse-Pakete (bzw. HMS) - ich denke das initiale Gerät "gateway_maplecun_00" ist falsch initialisiert, oder?

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 12:13:05
Ich habe es jetzt folgendermaßen umgebaut, geht leider trotzdem nicht:

define gateway_maplecun_zwcul ZWCUL X.X.X.X:2323 00000000 01
attr gateway_maplecun_zwcul 100k

define gateway_maplecun_zwave100k STACKABLE gateway_maplecun_zwcul
define z100k ZWCUL FHEM:DEVIO:gateway_maplecun_zwave100k:9600 00000000 01
attr z100k dataRate 100k
attr z100k room Bridges
attr z100k verbose 5

define gateway_maplecun_zwave40k STACKABLE z100k
define z40k ZWCUL FHEM:DEVIO:gateway_maplecun_zwave40k:9600 00000000 01
attr z40k dataRate 40k
attr z40k room Bridges
attr z40k verbose 5

define gateway_maplecun_zwave9600 STACKABLE z40k
define z9.6 ZWCUL FHEM:DEVIO:gateway_maplecun_zwave9600:9600 00000000 01
attr z9.6 dataRate 9600
attr z9.6 room Bridges
attr z9.6 verbose 5


Hat ggf. jemand ein funktionales Beispiel?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 12:20:04
Mir stellt sich auch die Frage, wie die einzelnen CC1101 den referenziert werden in diesem Beispiel.

Modul1: freq:868.300MHz
Modul2: freq:433.920MHz
Modul3: freq:868.300MHz
Modul4: freq:868.300MHz


Ich habe das so verstanden, dass jedes der drei 868MHz Module ja dann eine eigene Datenrate + Frequenz bekommt:

100k
40k
9600

Nun ist das Modul 2 ja ein 433 MHz Modul. Wie geschieht denn hier die Adressierung?

Ich glaube ich stelle mich gerade ganz schön dumm an  :'(
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 13:41:58
Ah, doch: er empfängt :)

Funktioniert.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 03 März 2019, 14:09:20
Falls jemand mal vor einer ähnlichen Situation steht. Das 1. Beispiel geht. Das 2. nicht - ich weiß (noch) nicht warum.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 23 März 2019, 17:22:10
Hi Telekatz,

ich habe einen Pull request im git gemacht um USB-Netzteilen zu sagen das sie doch bitte 500mA und nicht nur 100mA liefern sollen. Währe nett wenn du dir das mal ansehen könntest und dann einchecken. Habe regelmäßig Kunden den ich sagen muss das sie ein 500mA Netzteil nehmen sollen und nicht ein 2A Netzteil. 500mA Netzteile liefern meist immer die 500mA aber 2A Netzteile liefern bisher nur 100mA wenn das Gerät nicht mehr anfordert. 100mA sind nur leider zu wenig wenn ein CC1101 sendet. Das führt dann dazu das die Spannung kurz einbricht und der MapleCUN resetet.

https://github.com/heliflieger/a-culfw/pull/25


Lg Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maxel am 30 März 2019, 09:35:23
Hallo,

wo gibt es das 434Mhz-Modul welches auf die MapleCUN Large Platine passt?

Gruß Maxel

Gesendet von meinem WAS-LX1A mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 30 März 2019, 12:13:28
aliexpress: https://de.aliexpress.com/item/RTC1101-high-performance-wireless-FSK-transceiver-module-CC1101-radio-transceiver-chip-600-meters-1200bps-433-Mhz/32472259186.html

Oder schreibst mir eine PM. Hab genug hier davon :)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pnewman am 13 April 2019, 12:29:22
Hallo zusammen,

wenn ich den MapleCun/MapleCul richtig verstanden habe kann ich 4 Transceiver benutzen.
Z.B. 1x 433 für Steckdosen, 1x 868 für Homematic, 1x 868 für LaCrosse, 1x 868 für PCA301
Und ein Aufstzmodul für 868 MAX!

Habe ich das richtig verstanden?

Gruß
Ralf
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 13 April 2019, 13:52:47
Hallo Ralf,

PCA301 bzw. LaCrosse geht nicht mit dem maple CUN, nur mit dem Lacrosse GateWay.

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: arthur_dent_2015 am 13 April 2019, 14:07:14
Hallo Peter,

das ist so nicht ganz richtig. Lacrosse (HMS) ist implementiert (raw Nr1 bzw Nr2). Man muss im Zweifelsfall selber kompilieren. KölnSolar (Markus) arbeitet (hoffentlich noch  ;) ) an der Implementierung von PCA301. Siehe https://forum.fhem.de/index.php/topic,94589.0.html

Gruß
Arthur
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Prof. Dr. Peter Henning am 13 April 2019, 17:08:08
Ich bin mit dem Teil (bezogen von Eistee) ganz zufrieden. Allerdings ist auffällig, dass die mitgelieferte knappe Dokumentation im Widerspruch zum Wiki steht. Das sollte bitte auf der einen oder anderen Seite angepasst werden.

LG

pah
Titel: Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 13 April 2019, 21:13:51
Hallo pah,

das ist toll dSs Du das übernehmen willst! Du hast ja beide Informationen eh gerade gelesen und verstanden ;-)

Scherz beiseite: Was stimmt denn nicht?

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Markus. am 14 April 2019, 13:15:01
Zitat von: PeMue am 13 April 2019, 13:52:47
Hallo Ralf,

PCA301 bzw. LaCrosse geht nicht mit dem maple CUN, nur mit dem Lacrosse GateWay.

Gruß Peter

Hallo Peter,

Lacrosse geht mit dem maple, habe temp/hum sensoren laufen die vorher auf einem Lacrosse gateway liefen. Werden als hms devices erkannt.

Gruß

Markus
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dmq am 04 Mai 2019, 21:21:59
Hi,

ich habe einen CC2530 auf Ranseyers Zusatzplatine und setze es mit socat und zigbee2mqtt ein.

Zuerst hatte ich socat+zigbee2mqtt nur in einer screen-Sitzung am laufen. Nach 4-5 Tagen kamen aber immer wieder keine Sensordaten mehr rein. Wenn ich dann socat und zigbee2mqtt neugestartet habe ging es wieder. Nun wollte ich natürlich schlau sein und habe ein bash-Skript geschrieben, was diese beiden Komponenten jede Stunde stoppt und neustartet.

#!/bin/bash
/usr/bin/pkill -f socat
/bin/sleep 1
/usr/bin/nohup /usr/bin/socat pty,link=/dev/ttyTCP0,ignoreeof,user=root,group=dialout,mode=777,raw,b115200,echo=0 tcp:X.X.X.X:2324 &
/bin/sleep 2
/bin/systemctl restart zigbee2mqtt.service
exit 0


Nun ist es so, dass auch wieder nach ein paar Tagen keine Daten mehr kommen - zusätzlich bringt auch ein Neustart von socat+zigbee2mqtt nichts mehr. Ich muss den MapleCUN dann neustarten. Es ist nicht so, dass die TCP-Sitzung weg wäre (tcpdump und netstat geprüft).

Hat jemand eine Idee? Kann ich den MapleCUN eigentlich auch "per Software aus Ferne" neustarten?

Danke euch
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: subseven am 18 Mai 2019, 23:24:14
Zitat von: Markus. am 14 April 2019, 13:15:01
Hallo Peter,

Lacrosse geht mit dem maple, habe temp/hum sensoren laufen die vorher auf einem Lacrosse gateway liefen. Werden als hms devices erkannt.

Gruß

Markus

Mit der MySensors-Addon Platine geht auch PCA301. Ich hab einen 16Mhz Pro mini bei 3.3V laufen dem ein RFM69 Transreseiver zur Seite steht. Über die UART-Schnittstelle ist er entsprechend ansprechbar.
Ich kenn zwar die Entstehungsgeschichte zur MySensors Platine nicht, aber es lief nicht auf Anhieb. Der Jeelink konnte anfangs nur Daten empfangen und die PCA-Dosen nicht steuern. Es war dann erforderlich die Brücke zum rechten Kontakt an TX_SEL zu trennen und zum linken Kontakt zu verbinden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 07 Juli 2019, 11:36:00
@Telekatz
Ich möchte nur ungern einen STM32F103 schrotten! Von daher die Frage, ob der MSC Bootloader (https://github.com/Telekatz/MSC-stm32f103-bootloader) nach dem gleichen Prinzip (FTDI Adapter am seriellen Port) wie der DFU Bootloader geflasht werden kann oder ist dafür STLink/V2 erforderlich?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 07 Juli 2019, 12:18:10
Du kannst den STM32 immer über TTL flashen. Den kannst du nicht schrotten dadurch.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 07 Juli 2019, 14:14:41
Der MSC Bootloader wird genauso wie der DFU Bootloader geflasht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 09 Juli 2019, 15:24:29
Moin. Ich nutze aktuell noch eine mapleCUN auf nem Breadboard und hab den mit 2 CC1101 868 MHz laufen.
Den 2. nutze ich ausschließlich für 433 MHz.
Habe schon Platinen von Martin um weg vom breadboard zu kommen.
Allerdings finde ich bei Ali keine 433 MHz Stamps. Kann mir jmd. einen aktuellen Link geben?
Finde nur stamps mit Antenne rechts unten aber die Platinen sind mMn auf mittig ausgelegt.
Wird die Reichweite mit echtem 433 MHz Modul eigentlich größer?
Das ist bisher das einzige negative was ich mit meinem 868 Modul (auf 433) feststellen kann.

Gruß und Danke
Maui
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 09 Juli 2019, 15:33:17
Ja die Reichweite ist dann normal. bei einem 868MHz Modul welches du auf 433MHz betreibst hast du ja so gut wie keine Reichweite.
Wenn ich bei ali suche finde ich mehrere CC1101 Stamps mit 433MHz. Also einfach noch mal suchen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Reinhart am 09 Juli 2019, 20:15:15
@Maui

ich habe auch vor einigen Wochen von Martin Platinen bekommen und ebenfalls bei Ali 433er Module bestellt. ich habe die (https://de.aliexpress.com/item/32971834358.html?spm=a2g0s.9042311.0.0.74794c4dm5pT7M) genommen.


LG
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 09 Juli 2019, 21:57:13
Zitat von: Reinhart am 09 Juli 2019, 20:15:15
@Maui

ich habe auch vor einigen Wochen von Martin Platinen bekommen und ebenfalls bei Ali 433er Module bestellt. ich habe die (https://de.aliexpress.com/item/32971834358.html?spm=a2g0s.9042311.0.0.74794c4dm5pT7M) genommen.


LG

Das sind ja Wucherpreise. Mehr wie 2-3€ würde ich für so ein Modul nicht ausgeben.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 09 Juli 2019, 22:20:20
Zitat von: gloob am 09 Juli 2019, 21:57:13
Das sind ja Wucherpreise. Mehr wie 2-3€ würde ich für so ein Modul nicht ausgeben.
Sehe ich auch so. Hast du Zufällig einen Link? (Nein ich bin nicht zu faul zum suchen aber mit "CC1101 433 stamp" finde ich quasi nix passendes)

Gruss
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 09 Juli 2019, 22:30:07
Wie wärs mit etwas Lesen ?

Zum Beispiel wenige Posts weiter oben findest sich dieser Link: https://de.aliexpress.com/item/32472259186.html

(für 2€ ein gutes Modul mit richtigem CC1101 halte ich für unrealistisch! Daher finde ich für das seltenere 433MHz Modul unter 10€ gar nicht so schlimm. Aber: Selbst wenn es 10€ kostet und CC1101 drauf steht weiss man ja nicht was drin ist, und die einfacheren Chips erfüllen (zumindest bis jetzt) scheinbar auch ihren Zweck...)

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 10 Juli 2019, 06:57:41
Hi,
Die hier laufen gut:
€ 2,72 | RTC1101 high performance wireless FSK transceiver module CC1101 radio transceiver chip 600 meters 1200bps 433 Mhz / 315/868/915
https://s.click.aliexpress.com/e/b8LKiKYg
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Reinhart am 12 Juli 2019, 21:46:48
Zitat von: gloob am 09 Juli 2019, 21:57:13
Das sind ja Wucherpreise. Mehr wie 2-3€ würde ich für so ein Modul nicht ausgeben.

ihr solltet etwas genauer lesen, der Preis von meinem gepostetem Link mit 9,02.- ist für 2 Stück inkl. Drahtantenne und keine Versandkosten!
Der Preis vom oben geposteten Link beträgt inkl. Versandkosten dann 6,40.- (also teurer und ohne Antenne) für 1 Stück und bis zu 60 Tage Lieferzeit. Ich hatte meine in 16 Tagen und kann noch auswählen ob Rund- oder Halbloch.

LG

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 12 Juli 2019, 21:53:12
Also ich hab inkl. Versand im Schnitt 3,39€ pro Modul gezahlt. Von daher finde ich das schon ganz schön teuer.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 12 Juli 2019, 23:41:05
Naja Eistee wird wie ich 10 Päckchen oder mehr kaufen, da sin 3,5€ Versand halt nur 0,35€/Modul ;-)

Aber ich finde es sind alles Mondpreise! Wichtiger ist das die steile am Ende auch funktionieren!

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 15 Juli 2019, 17:22:07
Mahlzeit zusammen, ich hab mal im Wiki einen Eintrag zum Bootloader Flashen ohne TTL-Adapter eingefügt, da ich grad mal wieder einen maple damit geflasht habe.
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen_ohne_TTL-Adapter (https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen_ohne_TTL-Adapter)
Mit dem Bild bin ich selbst nicht so zufrieden, aber da es meine erste Berührung mit dem Wiki (schreibend) ist, hab ich es grad nicht besser hinbekommen.
Kommentare, Versuchskaninchen, Bild-besser-Einbinder sind willkommen.

Gruß
Maui
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 15 Juli 2019, 18:34:25
Warum sollte man ein zweites mal einen DFU fähigen bootloader flashen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 15 Juli 2019, 19:51:26
Naja es soll ja Leute geben die CUNs verkaufen.  ;)
Und dadurch irgendwann mal wieder einen jungfräulichen maple vor der Nase haben.
Und ich habe ja auch nie gesagt, dass man ein 2. mal den Bootloader flashen soll
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 29 Juli 2019, 18:55:34
Ich habe nochmals ein Update meiner Small-Version gemacht. Mehr Details gibt es im dazugehörigen Support-Thread:
https://forum.fhem.de/index.php/topic,97739.msg962357.html#msg962357

Kleine Stückzahlen der Platinen biete ich in einem Verkaufs-Thread an:
https://forum.fhem.de/index.php/topic,102637
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Wzut am 02 August 2019, 09:33:01
Ich habe mir hier im Marktplatz einen aufgebauten Maple gekauft ( LAN , 3 x 868 , 1x 433) und das HM-MOD-RPI-PCB selbst aufgelötet.
Platinenversion muß recht neu sein ( drei 1W  Löcher unten links, die beiden linken CC1101 schräg auf der Platine , kein Foto im Wiki)
Das FW Update des HM-MOD von 1.2.1 auf 1.4.1 habe ich via USB gemacht.
Nutze ich den Maple via USB ( ACM0 & ACM2 bzw via /by-id/ klappt auch alles. Ich muß allerdings später das Ding via Lan betreiben und hier fängt das Problem an  :
Das HMUARTLGW via uart://IP:Port wechselt ständig zwischen init & disconnent , ein paar Daten werden allerdings übertragen, denn nach einiger Zeit sind zwei,drei Readings vorhanden ( serialNr , version , .. ) allerdings sorgt das Spiel dafür das auch während dieser Zeit auf Port 2323 nichts mehr geht.
Im nächsten Versuch habe ich an den anderen freien UART einen TTL-USB Adapter gehängt und zwei Fenster aufgemacht.
Fenster 1 putty auf den TTL-USB ( dev/USB0) Fenster 2 auf USB des Maple (dev/ACM1) Schreibe ich nun beliebigen Text in Fenster 1 wird er in Fenster 2  angezeigt und auch umgekehrt , d.h. alles wie es sein soll.
Bei Test 2 habe ich in Fenster 2 statt dem USB Terminal eine Telnet Sitzung auf Port 2324 aufgemacht.
Nun kann ich beliebigen Text ins Telnet Fenster2 schreiben und  er wird auch fehlerfrei in Fenster 1 angezeigt.
In die andere Richtung schaffe ich max 3 bis 5 Zeichen einzugeben, diese werden zwar noch richtig im anderen Fenster angezeigt , allerdings bricht dann die Telnet Sitzung ab.
D.h. mein Maple kann zwar via TCP auf die beiden UARTs senden, aber wenn diese dann antworten wollen kommt er komplett aus dem Tritt.
Ich habe nun diesverse Stromversorgungen durch (USB & Hohlbuchse) und auch FW Updates , alles ohne Erfolg
Bin nun mit meinem Latein am Ende, irgend jemand noch eine Idee ?       
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 August 2019, 12:00:37
Meist hilft das komplette mehrfache abarbeiten von diesem: https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres

Das muss zuerst stabil laufen:
ZitatDas HMUARTLGW via uart://IP:Port wechselt ständig zwischen init & disconnent

Dafür kommt in Frage:
-Spannungsversorgung (mit LAN-Modul deutlich höherer Bedarf!)
-Firmware alt und 2A Netzteil (bei dir wohl nicht der Fall)
-LAN oder LAN-Modul fehlerhaft

Wenn es doch ein HW-Problem sein sollte (was ich nicht glaube): Lieferant fragen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 02 August 2019, 13:37:58
Welches WIZnet Modul ist auf deinem Maple? Dann kann ich mal versuchen das nachzustellen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Wzut am 02 August 2019, 13:51:37
THX, das W5500
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 August 2019, 13:54:46
ZitatDas HMUARTLGW via uart://IP:Port wechselt ständig zwischen init & disconnent
Bonusfrage: Wie in FHEM eingebunden ? -Also die alte oder neue Methode ?
https://wiki.fhem.de/wiki/MapleCUN#Einrichtung_in_FHEM_.28alt.29

Grund: Es gibt weiterhin das ganz vereinzelte Gerücht, dass die neue  Methode genau deine Fehler erzeugt. (Ich kann das nicht bestätigen, aber auch nicht widerlegen... Habe das Problem nicht.)


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Wzut am 02 August 2019, 14:19:46
alt , also STACKABLE_CC
aber das als Grund glaube ich nicht, denn die Art der Anbindung auf Port 2323 hat doch mit dem TCP Port 2324/25 der auf einen der beiden UARTSs durchgereicht wird direkt nichts zu tun. Aber du könntest mir helfen die Debug Schnittstelle zu beleben.
Durch das HM Modul kann ich von der Beschriftung oben rechts nur noch den ersten Pin GND lesen , alles weitere liegt unter dem Modul und ich finde kein Foto von dieser neuen Platinen Version. Ich wollte mir schon damit behelfen Debug an der 2x5 Buchsenleiste für den ESP abzugreifen, aber da kommt z.Z. nichts an
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 02 August 2019, 14:33:23
Blöde Frage: Du hast auf dem maple auch eine ältere Version, bei der Debug noch dabei ist?  ;)

Gruß
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Wzut am 02 August 2019, 14:37:45
genau das hatte ich hier im Thread bzw. Wiki nicht so recht verstanden, bis zu welcher FW Version ist Debug noch per default aktiv ?
denn seit gestern ist die  V1.26.07 a-culfw Build: 319 (2019-07-02_21-49-24) drauf
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 02 August 2019, 14:49:52
Man kann es anhand der Download Zahlen erahnen.
1.26.01 ist die letzte mit debug.
Steht auch hier irgendwo im Thread.

Gruß
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 August 2019, 16:54:55
Evtl. hat ja mal jemand Lust das ins Wiki zu schreiben...?

Wenn sich die Info wieder findet muss man nicht immer so schwammig Antworten...

Gesendet von meinem VTR-L09 mit Tapatalk

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 02 August 2019, 17:32:48
Es war ein Bug in der Firmware. Ist gefixt mit Version 1.26.08.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: papa am 02 August 2019, 23:13:10
Wenn Du LAN nutzen willst, darfst Du am USB keinen Rechner haben, da sonst automatisch auf USB gewechselt wird. Das selbe kenne ich vom Max-Cube. Denn hatte ich am USB-Port einer Fritzbox zur Stromversorgung - aber per LAN in FHEM eingebunden. Das ging auch nicht, bis ich die Spannungsversorgung auf eine einfaches USB-Netzteil umgestellt habe.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Wzut am 03 August 2019, 08:18:21
Zitat von: Telekatz am 02 August 2019, 17:32:48
Es war ein Bug in der Firmware. Ist gefixt mit Version 1.26.08.
vielen Dank, ich werde testen und berichten
@papa, ja ist klar. Ich hatte bei meinen Tests auch nie USB aktiv und Lan gleichzeitig genutzt, denn das Problem mit dem CUBE habe ich auch schon hinter mir :)
(und meinem Cube an der FB habe ich damals die Datenleitungen durchgeschnitten)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Wzut am 03 August 2019, 14:05:52
@Telekatz, der HM-MOD-UART läuft nun via Port 2325 !!! vielen Dank für die super schnelle Hilfe :)
Nur mal aus Neugier : wie lang war der Bug denn schon drin? Wundert mich schon das bisher noch niemand darüber gestolpert ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 03 August 2019, 15:59:30
Der Bug kam Mit der Version 1.26.06 vor etwa 4 Monaten rein.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 15 August 2019, 16:19:00
Hallo

Ich habe jetzt mir ein Maple Board gekauft und versuche es zu Flashen.
Leider Komme ich nicht weiter.
Wenn ich unter CMD C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win>dfu-util --list
bekomme ich diese Meldung."Der Befehl "C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win" ist entweder falsch geschrieben oder
konnte nicht gefunden werden."

Ich habe aber unter diesem Pfad die Datei liegen.

Brauche ich ein anderes Programm ?

Ich würde mich freuen wenn jemand weiterhelfen könnte.

Grüße André

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 August 2019, 16:26:48
Der Befehl beginnt mit dfu-util...
Davor ist nur der Pfad. Den lässt du weg...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 15 August 2019, 17:15:31
Zitat von: rieders am 15 August 2019, 16:19:00
C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win>dfu-util --list


Grüße André

Hi,
Versuch doch mal;

cmd.exe
C:
cd \tmp\Arduino_STM32master\Arduino_STM32-master\tools\win
dfu-util --list


Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 16 August 2019, 10:41:51
Hallo RaspiLED und Ranseyer

Vielen Dank für die Hilfe.
Ich habe es irgendwie geschafft die China Maple zu Flashen.

Nun habe ich ein ESP8266 auf die Leiterplatte gemacht. Den habe ich vorher mit ESP-Link geflasht mit der aktuellsten Firmware.
Wenn ich Ihn auf dem CUL Board aufstecke passiert aber nichts. Er verbindet sich nicht mit dem Netzwerk.
Muss ich auf dem Board noch etwas überbrücken ?

Wenn ich den ESP nur mit 3.3v und GND anschließe passiert auch nichts.
Nur wenn ich mein Flashtool anschließe bekomme ich eine Verbindung zum Netzwerk.

Auf dem Cun Board habe ich bis jetzt nur den Maple und den ESP drauf. Noch keine Funkmodule.

Achso bei der neusten Jee-Link Firmware ist ein neuer Punkt " TX Enable " sollter der auf ein GPIO?


Grüße und Vielen Dank für die Hilfe

André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 16 August 2019, 14:43:06
Hallo Nochmal

Ich habe jetzt nochmal dfu-util --list ausgeführt und ich bekomme diese Fehlermeldung( Anhang).


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 16 August 2019, 14:47:36
Hallo André,

da du 3 Geräte angezeigt bekommst gehe ich mal davon aus das das die 3 seriellen Schnittstellen sind. Damit du mit dem dfu-util den stm32 flashen kannst musst du ihn in den DFU Modus bringen.

LG Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 16 August 2019, 15:03:41
Ja das habe ich ja gemacht.
Wenn ich unter Fhem jetzt da Device anlege bekomme ich den Status disconnected. (/dev/serial/by-id/usb-STM32_MAPLECUL_USB__6a18bd5d-if0@38400 4444)
Wobei ich nicht weiß ob hinter If 00 richtig sein könnte. Geht aber beides nicht.

Reset am Maple Mini zweimal innerhalb einer Sekunde drücken.
Die Firmware Datei auf das vom Bootloader bereitgestellte USB-Laufwerk kopieren.
Ich habe kein USB-Laufwerk bekommen


Mit dem ESP - bekomme ich auch keine Verbindung zum Wlan.


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 16 August 2019, 15:17:25
Moment mal. Irgendwie wirfst du hier Windows und Linux durcheinander.
/dev/serial/by-id/Das ist eindeutig Linux

C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win>dfu-util --listDas ist Windows

Was zum Geier willst du denn überhaupt machen?

Und was hat der ESP mit dem Maple zu tun? Der ESP mit ESP Link ist doch nur eine Schnittstelle um einen uart über WLAN ansprechen zu können. Damit das geht darfst du beim MapleCUN keinen Computer am USB anschließen sondern nur ein Netzteil. Und wenn dein ESP nicht ins WLAN geht dann hast du ihn wahrscheinlich schon mal nicht richtig geflasht denn der ESP ist ein eigener Controller der völlig unabhängig vom MapleCUN läuft.

Schreib uns doch am besten erst mal was du vor hast statt irgendwelche Befehle die du k.A. woher hast die angeblich nicht gehen.

LG Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 16 August 2019, 16:02:31
Hallo

Ich habe ein Maple Cun/Cul Board v4.
Darauf habe ich ein geflashten Maple und ein ESP 01 Modul.
Ein Funkmodul 433 MHZ ist an Ant 1 verlötet.

Ich mochte meine Nanocul´s durch ein MapleCun/Cul ersetzen.
Da er auch W-Lan fähig ist könnte ich ihn so paltzieren das auch alle Funkgeräte stabil erkannt werden.

Ich weiß das C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win>dfu-util --list zu Windows gehört.

Und Fhem läuft bei mit auf einem Banana Pi. Also Linux deshalb auch /dev/serial/by-id/usb-STM32_MAPLECUL_USB__6a18bd5d-if0@38400 4444

Die Befehle habe ich von https://wiki.fhem.de/wiki/MapleCUN und von https://wiki.fhem.de/wiki/MapleCUX-Platinen.


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 16 August 2019, 16:05:17
und was möchtest du mit dfu-util tun wenn der Maple doch schon geflasht ist?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 16 August 2019, 16:37:55
Mich wundert nur die unterste Zeile mit dem Error.

Und warum funktioniert der ESP nicht, auch wenn ich ein Netzteil anschließe und das USB-Kabel weg lasse?


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 16 August 2019, 18:12:33
Wie wäre es mit einem schrittweisem Start.

Erst mal den MAPLE-CUN per USB an den Rechner hängen und Erfahrungen sammeln. Wenn es läuft, den ESP als schlechtes USB Kabel betrachten... Der funktioniert nur wenn richtig konfiguriert... (ich habe das noch nie probiert zu diesem Zweck)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 16 August 2019, 18:46:34
Hallo Ranseyer

Wie gehe ich da vor ?
Ich habe den Maple auf das V4 board gelötet und per USB am PC hängen.
Auf dem Board sind noch keine Funk-Module verbaut.
Im Geräte-Manager habe ich unter Kommunikationsanschluss 2 Serielle USB-Geräte.

Unter libusbk habe ich ein Maple Cul (interface 0).

Ich hoffe das es soweit ok ist ?

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 16 August 2019, 21:39:38
Ein Funkmodul wäre schon hilfreich...
(notfalls gesteckt auf dem Steckplatz, oder doch besser gleich verlötet. Kostet ja nicht viel.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 17 August 2019, 06:46:04
Guten Tag.
Ein CC1101 433 Mhz habe ich an ANT 1 gelötet.

Wie soll ich weiter vorgehen.

Ich habe den Maple am Raspberry pi hängen und er wurde initialisiert.
Da ich noch keine Antenne angelötet habe bekomme ich wahrscheinlich keine Signale.(Revolt Gerät wurde erkannt)
Die Teile befinden sich noch im Zulauf.

Ich werde noch ein 868mhz Modul verbauen was ich noch habe.


Grüße
André

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 17 August 2019, 13:08:32
Hi,
Ein Stück Draht als Antenne wäre eine Zwischenlösung.
https://wiki.fhem.de/wiki/CUL#Antennenl.C3.A4nge
Ohne würde ich das lieber nicht betreiben bzw. auf keinen Fall etwas senden!
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 18 August 2019, 09:36:07
Hallo

Vielen Dank für den Link zu den Antennen.
Ich werde warten bis ich die "richtigen" Antennen und Anschlüsse bekomme.
Dann werde ich nochmal berichten wie der Status ist.



Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 18 August 2019, 10:17:40
Zitat
... Ich habe jetzt nochmal dfu-util --list ausgeführt und ich bekomme diese Fehlermeldung:
... load to RAM not supported ....

Sieht doch so aus, als ob der BOOT0-Pin (https://github.com/leaflabs/maplemini/blob/master/maplemini.pdf) beim Flashen nicht auf Masse liegt ?

Wobei ... das bei --list auch nur eine Info sein könnte ...  ;D

Grüße,
Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 18 August 2019, 10:46:14
Hallo Juergs

Ja das hatte ich nicht gemacht.
Muss ich das nur beim Bootloader mache oder auch wenn ich das Programm flashe?

Vielen Dank für die Info.

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 18 August 2019, 10:57:10
ZitatMuss ich das nur beim Bootloader mache oder auch wenn ich das Programm flashe?

Ich kenne Ranseyers Aufbau gerade nicht im Detail, aber ich lasse die Brücke BOOT0 zu Masse einfach drin ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 18 August 2019, 12:22:50
Hallo

Ich habe jetzt nochmal dem Bootloader mit der Brücke aufgespielt und dann --List ausgeführt.
Das Ergebnis ist das Gleiche.

Jedenfalls sieht es nicht so aus.
C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win>dfu-util --list
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=0, name=""
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000"
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000"

Bei meinem Maple ist es so.
C:\tmp\dfu-util-0.9-win64\dfu-util-0.9-win64>dfu-util --list
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="2-2", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="2-2", alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=5, cfg=1, intf=0, path="2-2", alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"

Grüße
André

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 18 August 2019, 13:14:22
Hallo André,

bitte pack Deine Ausgaben in Code Tags (# oben in der Leiste), dann sind sie viel besser lesbar.

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pancho am 18 August 2019, 13:21:26
PIN3 = GPIO0: Low beim Start aktiviert Firmware-Upload, muss zum normalen Start offen sein oder auf High liegen-> heißt muss nur während des bootens auf GND um den Flashmode einzuleiten

kleine Anmerkung zum ESP-Link flashen : ich benutze einen ESP-01 (schwarz) welches laut verbautem Flash Chip P25Q80H = 8MBit=1MB Speicher hat.
Es scheint aber leider so, dass der Bootloader das Flash nicht richtig  erkennt und so nur mit 512K funktioniert.
Laut Bootlog: "SPI Flash Size & Map: 4Mbit(256KB+256KB)"
Hatte auch erst nur die 1MB-Variante probiert ohne Erfolg SW-Bootet und resetet zyklisch.
ESP geflasht mit 512K funktioniert ....

Ich kann nun den MapleCun erfolgreich über WLAN mit Port 2323 erreichen kann aber auf die zusätlichen seriellen mit Port 2324 und 2325 nicht zugreifen.
Kann es sein das die ESP-Link SW die Ports nicht durchreicht ?

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 18 August 2019, 13:25:23
Die ESP-Link Firmware ist ein UART zu Telnet Schnittstelle mit WLAN Anbindung. Die kennt keinen Port 2323 und auch keine 2 anderen Ports sondern nur einen Port 22 der die UART Schnittstelle des ESP8266 ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: pancho am 18 August 2019, 14:37:50
Ok Danke, hab mir sowas schon fast gedacht....
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 18 August 2019, 14:57:57
@Andre: mir (unterwegs im Urlaub mit Handy ) ist ehrlich nicht klar ob du ein Problem hast und welches. Habe mir von oben gemerkt, dass du drei neue serielle Schnittstellen hast.

Das würde heißen Bootloader und Firmware sind OK.
Kannst du nochmal zusammen fassen was du genau gemacht hast und was nun das Problem ist?

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 18 August 2019, 19:23:10
Hallo

Ich habe 2 Com Schnittstellen hinzubekommen und ein libusbK Device.
Gemacht habe ich:
Bootloader : maple_mini_boot20 und danach
Firmware : MapleCUNx4_W5500_BL installiert.

ESP (schwarz)mit aktueller Jee-Link Firmware auf Maple Board v4 aufgelötet.
CHPD1 Brücke gescklossen.

Externe Spannungsversorgung, Sicherung und 5v Spannungswandler 1117 verbaut.

Wenn ich das in dem vorhergehenden Eintrag richtig verstehe bekomme ich über den ESP einen Com bereit gestellt.
Kann ich darüber dann alle Funkmodule erreichen ?

Ich habe noch ein blauen ESP, ist er besser geeignet ?

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 18 August 2019, 21:39:02
Zitat von: rieders am 18 August 2019, 19:23:10
Hallo

Ich habe 2 Com Schnittstellen hinzubekommen und ein libusbK Device.
Gemacht habe ich:
Bootloader : maple_mini_boot20 und danach
Firmware : MapleCUNx4_W5500_BL installiert.

ESP (schwarz)mit aktueller Jee-Link Firmware auf Maple Board v4 aufgelötet.
CHPD1 Brücke gescklossen.

Externe Spannungsversorgung, Sicherung und 5v Spannungswandler 1117 verbaut.

Wenn ich das in dem vorhergehenden Eintrag richtig verstehe bekomme ich über den ESP einen Com bereit gestellt.
Kann ich darüber dann alle Funkmodule erreichen ?

Ich habe noch ein blauen ESP, ist er besser geeignet ?

Grüße
André

Sag mal hast du das Wiki eigentlich gelesen? Was soll die Jeelink Firmware auf dem ESP?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 19 August 2019, 04:30:59
Hallo gloob

Eigentlich schon.
https://wiki.fhem.de/wiki/MapleCUX-Platinen

Debug UART als Uplink z.B. mit ESP8266
Statt per USB oder LAN kann der MAPLE-CUl auch in WLAN eingebunden werden. Auch wenn diverse Leute von der WLAN-Anbindung von Heimautomatierungskoponenten abraten, so ist das möglich.

esp-link Konfiguration:

Home / Pin assignment:
Reset: disabled
ISP/Flash: disabled
Conn LED:  disabled
Serial LED: disabled
UART pins: normal
RX-PullUp: aktiv
µC Console:
Baud: 115200
Fmt: 8N1
Debug log:
UART debug log: off
Esp-link settings.JPG

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 19 August 2019, 08:03:29
Zitat von: rieders am 18 August 2019, 19:23:10
ESP (schwarz)mit aktueller Jee-Link Firmware auf Maple Board v4 aufgelötet.

Zitat von: gloob am 18 August 2019, 21:39:02
Was soll die Jeelink Firmware auf dem ESP?

Zitat von: rieders am 19 August 2019, 04:30:59
esp-link Konfiguration:
Vermutlich (hoffentlich) ist das nur eine Namensverwechslung. Sowohl der Jeelink (https://www.digitalsmarties.net/products/jeelink) als auch die Software esp-link (https://github.com/jeelabs/esp-link) ist von der Firma Jeelabs (https://github.com/jeelabs/esp-link). Der JeeLink Sketch, den gloob meint, ist der für den JeeLink (https://wiki.fhem.de/wiki/JeeLink), der die Daten von diversen Sensoren empfängt.

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 19 August 2019, 19:47:49
Hallo

Ich habe jetzt einen "Blauen" ESP mit der esp-Link Firmware auf das Board gesteckt.
Leider finde ich den ESP nicht mehr im Netzwerk.

Irgendwie funktioniert das mit dem esp und dem Board nicht so richtig.
Der ESP scheint gar nicht zu starten.

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 19 August 2019, 19:49:29
Zitat von: rieders am 19 August 2019, 19:47:49
Hallo

Ich habe jetzt einen "Blauen" ESP mit der esp-Link Firmware auf das Board gesteckt.
Leider finde ich den ESP nicht mehr im Netzwerk.

Irgendwie funktioniert das mit dem esp und dem Board nicht so richtig.
Der ESP scheint gar nicht zu starten.

Grüße
André

Am Board liegt es nicht. Ich hatte das Board mit ESP laufen.
Zeig doch mal ein paar Bilder von der Vorder- und Rückseite deines Boards.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 19 August 2019, 20:04:26
Ich habe jetzt 2 Boards.

Ein Board hat die Externe Spannungsversorgung und die Kondensatoren.

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 20 August 2019, 18:56:47
Hallo

Ist auf den Bildern ein Fehler zu finden ?

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 20 August 2019, 21:09:46
Zitat von: rieders am 20 August 2019, 18:56:47
Hallo

Ist auf den Bildern ein Fehler zu finden ?

Grüße
André


Hi,
CHPD1 ist auf einem offen. Ist das die Groundverbindung des Boot PINs des ESP?
Wie muss die sein?
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 21 August 2019, 04:41:54
Hallo RaspiLED

Ja ich habe die Verbindung wieder geöffnet.
Die sollte zwingend geschlossen sein um den ESP zu starten.
Da wird der Spannungsregler 5V aber sehr warm, deshalb hatte ich die 3,3V Verbindung wieder geöffnet.

Auch bei dem anderen Board bekomme ich keine Verbindung über das W-Lan hin.


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 23 August 2019, 19:26:43
Hallo

Heute habe ich mein w5500 Modul bekommen.
Leider bekomme ich damit auch keine Verbindung zum Lan hin.
Zwar leuchtet das Modul aber es blinkt nur gelbe Netzwerklampe.
Die grüne leuchtet dauerhaft. Die rote LED ist natürlich auch an.

Der MapleCUL sollte doch eigentlich das Modul erkennen und eine Verbindung aufbauen ?

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 23 August 2019, 19:36:21
Hast du die richtige Firmware geflasht?
Warum bringst du das Ding nicht erstmal über USB zum laufen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 23 August 2019, 19:36:36
Hast du schon alles elektrisch durchgeprüft?
Oft ist die Netzwerkbuchse hinten am USR-ES1 schlecht gelötet.
Poste doch mal die Debug Ausgabe vom UART0.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 23 August 2019, 19:46:22
Hallo Eistee

Ich werde es die nächsten Tage überprüfen und melde mich dann nochmal.

Vielen Dank für die schnelle Antwort.



Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 23 August 2019, 20:15:22
... wenn dein Router per DHCP die IP Adressen vergibt, kannst du auch dort nachschauen ob zwischen LAN Buchse und LAN Modul alles OK ist. Wenn also eine IP Adresse vergeben wurde ist das LAN Modul und LAN OK.

Unklar ist dann der Anschluss des LAN Moduls und die Firmware...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 25 August 2019, 09:38:30
Hallo

Ich habe am selben Anschluss wie ich auch den Bootloader hoch geladen habe den Maple mit einem USB Serial Adapter verbunden.
Unter Arduino Serial bekomme ich keine Infos ausgegeben.

Muss ich ein anderen Anschluss verwenden ?

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 25 August 2019, 09:53:33
Zitat von: rieders am 25 August 2019, 09:38:30
Hallo

Ich habe am selben Anschluss wie ich auch den Bootloader hoch geladen habe den Maple mit einem USB Serial Adapter verbunden.
Unter Arduino Serial bekomme ich keine Infos ausgegeben.

Muss ich ein anderen Anschluss verwenden ?

Grüße
André

Warum verbindest du den Maple nicht einfach mit einem normalen USB Kabel mit deinem Rechner?

Weißt du eigentlich was du da machst? Du stocherst da seit Wochen blind rum.
Vielleicht solltest du lieber einen fertigen MapleCUL hier im Forum oder bei "Eistee" kaufen: https://alinamosig.jimdofree.com
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 25 August 2019, 10:14:18
Ich bastel gerne und versuche es auch zum laufen zu bringen.

Die Kategorie heißt doch Bastelecke.

Ist doch nicht schlimm wenn hier fragen stelle. oder ?
Nun so kann doch von euch lernen.

Wenn ich per USB auf die Com-Ports zugreife passiert auch nichts.


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 25 August 2019, 10:40:13
Was sagt "lsusb"
Wie hast du den MapleCUN in FHEM eingebunden?
Gibt es Fehlermeldungen im FHEM Log wenn du das Device auf verbose = 5 stellst?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 25 August 2019, 12:17:09
Ich habe es mit Netzwerk eingebunden define MAPLECUL1_868 CUL 192.168.1.xx:2323 1234
Verbose 5 gestellt.
Ich habe auch nur 2 Module verbaut.
Meine Adapter für die Antennen habe ich noch nicht bekommen.

In der Fhem Log habe ich keine Fehlermeldung bekommen.


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 25 August 2019, 12:39:43
Woher hast du denn eine IP Adresse wenn du oben schreibst das er sich nicht mit dem Netzwerk verbindet? Ich glaube nicht das du weißt was du da tust. Hilfreich wäre die Debugausgabe der a-culfw die du ja leider nicht postest. Da könnte man zumindest sehen ob der STM32 deine Funkmodule und das Netzwerkmodul erkennt und ob er sich eine IP holt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 25 August 2019, 12:41:04
Versuch doch erstmal das Ding mit USB zum laufen zu bekommen und dann können wir LAN danach angehen.

Was kommt wenn du den MapleCUN per USB an den Rechner wo FHEM lauft steckst und in der Console folgendes eingibst:
lsusb

Wie hast du den MapleCUN in FHEM eingebunden? Poste bitte mal ein list vom MapleCUN Gerät.
Dafür auf der FHEM Webseite oben folgendes eingeben:
list MAPLECUN_NAME
MAPLECUN_NAME bitte durch den richtigen FHEM Namen ersetzen.

Gibt es Fehlermeldungen im FHEM Log wenn du das Device auf verbose = 5 stellst?
Poste bitte mal die Zeilen aus dem Log, die direkt nach dem Neustart von FHEM kommen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 25 August 2019, 12:48:26
FHEM Einbindung ist erstmal nebensächlich solang nicht klar ist ob er die Hardware richtig zusammen gelötet hat und die Firmware geflasht bekommen hat. Ich vermute das er noch gar keine firmware drauf hat. zumindest schrieb er mal das dfu-util nicht geht und ich hab auch noch nicht gelesen das er es hinbekommen hat.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 25 August 2019, 12:51:09
Okay ich dachte über den Punkt hat er es endlich mal geschafft.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 25 August 2019, 18:26:04
Genau

wenn ich wüsste wie ich die Debugausgabe hin bekomme, würde ich es posten.

unter Raspi
root@Smart-HomeRaspi4:~# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0483:5743 STMicroelectronics
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@Smart-HomeRaspi4:~# list STMicroelectronics
-bash: list: Kommando nicht gefunden.
root@Smart-HomeRaspi4:~#


Grüße
André

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 25 August 2019, 18:45:24
Zitat von: rieders am 25 August 2019, 18:26:04wenn ich wüsste wie ich die Debugausgabe hin bekomme, würde ich es posten.

Les mal ab hier: https://forum.fhem.de/index.php/topic,60458.msg812357.html#msg812357
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 25 August 2019, 19:07:36
Achso

Der Debugausgang muss erst in der Firmware aktiviert werden.

Ok. Dann werde ich das mal nächste Woche in Angriff nehmen.
Wie lange brauche ich denn wenn ich dein Gehäuse für den Maple nachdrucken möchte, Eistee ?


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 25 August 2019, 19:58:50
Zitat von: rieders am 25 August 2019, 18:26:04
Genau

wenn ich wüsste wie ich die Debugausgabe hin bekomme, würde ich es posten.

unter Raspi
root@Smart-HomeRaspi4:~# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0483:5743 STMicroelectronics
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@Smart-HomeRaspi4:~# list STMicroelectronics
-bash: list: Kommando nicht gefunden.
root@Smart-HomeRaspi4:~#


Grüße
André

Das sieht jetzt aber nicht danach aus, dass der richtige Bootloader auf dem STM32 drauf ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 25 August 2019, 20:28:14
@rieders: Lernen ist immer gut. Verzweiflung nicht.

Wenn es dir reicht : schick mir nen PN und ich flashe das Teil für dich.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 26 August 2019, 00:40:53
Zitat von: rieders am 25 August 2019, 19:07:36Wie lange brauche ich denn wenn ich dein Gehäuse für den Maple nachdrucken möchte, Eistee ?
Das sagt dir deine Slicer Software doch. Ich kann leider keine Aussage zu tausenden 3D Druckern geben die es wohl inzwischen gibt. Ganz zu schweigen von den selbst gebauten Druckern.
Außerdem habe ich auf deinen Bildern gesehen das du eine andere Leiterplatte verwendest die wohl nicht zu meinem Gehäuse passen wird.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 26 August 2019, 07:15:36
Zitat von: rieders am 25 August 2019, 19:07:36
Wie lange brauche ich denn wenn ich dein Gehäuse für den Maple nachdrucken möchte, Eistee ?

Ob folgendes Gehäuse auch für die 4.0 passt kann ich dir leider nicht sagen, aber für den Vorgänger hat sie gepasst. Druckt dauert etwa 3Stunden pro Teil.

https://www.thingiverse.com/thing:3673446
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 26 August 2019, 08:56:12
Zitat von: gloob am 26 August 2019, 07:15:36
Ob folgendes Gehäuse auch für die 4.0 passt kann ich dir leider nicht sagen, aber für den Vorgänger hat sie gepasst. Druckt dauert etwa 3Stunden pro Teil.
https://www.thingiverse.com/thing:3673446

Natürlich passt es ! Nur falls man 1Wire nutzen möchte braucht man noch eine Feile und eine Minute Zeit...
(Selbst einige der Erweiterungen passen direkt in Gloobs Gehäuse. Bei nem CC2530 in der "bedrahteten Ausführung" wird die Höhe wohl nicht reichen. Als Stamp und per SMD aufgelötet passt selbst der CC2530...)

PS: Ich habe noch eine Trägerplatine um MAPLE-CUL Erweiterungen ohne MAPLE-CUL zu nutzen. Statt dessen hängt man diese mittel TCP232 Modul von USR ans LAN. Auch da passt prinzipiell das Gehäuse. Zumindest die LAN Buchse. Das werde ich aber in einem separaten Thread beschreiben. Hier passt das nicht.)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 26 August 2019, 12:12:50
Moin zusammen,
Ich habe ein MapleCUN, der prinzipiell funktioniert.
Allerdings würde ich gerne die MAX-Credits hochsetzen von 900 auf 3600. Nicht aus Langeweile, sondern weil ich mit den 900 nicht hinkomme.
Ich habe a-culfw auch selbst kompiliert bekommen und die Firmware läuft auch prinzipiell, also die Kommunikation zwischen fhem und CUN sowie CUN und MAX Komponenten auch.
Allerdings kriege ich keine neuen Geräte gepairt mit der selbst gebauten Firmware.
Hat evtl. Einer von euch eine Idee, woran das liegen könnte?
Zur Not könnte ich natürlich zum pairen die Firmware kurzzeitig wechseln, aber das wäre nur als Notlösung denkbar.

Gruß
Maui
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 26 August 2019, 12:50:08
Seit der Version 1.26.02 vor 1,5 Jahren ist der Credit schon auf 3600 für den Cube und MapleCUN hochgesetzt. Wenn die Firmware auf dem MapleCUN nicht älter war, wird es mit selber kompilieren auch nicht besser.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 26 August 2019, 15:04:06
Hallo

Vielen Dank für die Infos und das Bild.

Ich werde dann mal ein Gehäuse drucken, das sieht ja gut aus.

Könntest du dann mal den Link für die extra-Platine senden.
Ich kann mir das noch nicht so richtig vorstellen wie das aussieht.

Ich hoffe das meine Antennenadapter bald da sind.

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 26 August 2019, 15:29:35
Zitat von: Telekatz am 26 August 2019, 12:50:08
Seit der Version 1.26.02 vor 1,5 Jahren ist der Credit schon auf 3600 für den Cube und MapleCUN hochgesetzt. Wenn die Firmware auf dem MapleCUN nicht älter war, wird es mit selber kompilieren auch nicht besser.
Danke. Hatte zuvor die 1.26.01 drauf, da ich anfangs auf debug angewiesen war.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 26 August 2019, 21:06:10
ZitatIch hoffe das meine Antennenadapter bald da sind.

Löte doch einfach ein Stückchen Draht mit knapp 10 cm dran.

Wenn fertig: Kürzen:
ZitatBei 868 MHz ist die Wellenlänge 34,5 cm, eine Lamda/4-Antenne müsste also 8,6 cm lang sein,

Besser könnte 84-85 mm sein aufgrund der realen Welt  => ausprobieren...


PS: Das gilt dann nur für die grüne Stamp !
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 26 August 2019, 21:20:39
Zitat von: Maui am 26 August 2019, 15:29:35
Danke. Hatte zuvor die 1.26.01 drauf, da ich anfangs auf debug angewiesen war.

Ich habe das jetzt endlich mal ins Wiki geschrieben...
https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres

Problem: Der Artikel ist inzwischen ziemlich unübersichtlich geworden.


Außerdem überlege ich schon länger wie man das Flashen vereinfachen könnte.

-Die Tools von STM dürfen in der Lösung nicht enthalten sein (rechtlich)
-Eine Windows PE Live-CD geht auch nicht (rechtlich)
-Eine VM wird für den Tausch des Bootloaders gut funktionieren, kaum jedoch für das Flashen per USB Bootloader innerhalb einer Sekunde und ohne das USB Gerät der VM zum Durchreichen bekannt zu machen...
-DFU-Util unter Windows (geht nur mit LibUSB und auch das ist nicht ganz pflegeleicht)
-Bliebe noch eine Linux-Live CD, ist relativ einfach zu erstellen. Aber bekommt das Teil jeder gestartet und lohnt sich der Aufwand dafür ?

(Und @Telekatz: Die Nutzung des normalen Maple-Bootloaders willst du weiterhin nicht unterstützen ? Dann wäre ein Teil weniger)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 26 August 2019, 23:20:10
Zitat von: Ranseyer am 26 August 2019, 21:20:39
Ich habe das jetzt endlich mal ins Wiki geschrieben...
Danke.

Außerdem überlege ich schon länger wie man das Flashen vereinfachen könnte.
Ich frage mich ob das flashen vielen Probleme bereitet. Ich denke mir jemand, der Teile auf eine Platine lötet, kann den CUN auch flashen.
Das bootloader flashen geht ja schon ohne TTL und ist ja ne einmalige Sache und dfu-util finde ich persönlich unter windows auch ziemlich straight.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 27 August 2019, 12:52:24
Zum einfachen flashen gibt es seit kurzen den MSC Bootloader (https://github.com/Telekatz/MSC-stm32f103-bootloader/releases). Das DFU-Util ist damit nicht mehr notwendig und eine .bin Datei auf ein USB-Laufwerk zu kopieren sollte jeder schaffen.

Zum updaten vom Maple-Bootloader auf den MSC Bootloader gibt es hier (https://github.com/Telekatz/MSC-stm32f103-bootloader/tree/master/maple_mini_bootloader_updater) auch ein Update Sketch, der mit der Arduino IDE geladen werden kann.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 29 August 2019, 12:13:10
Danke für den Input. (Ich hatte den MSC-Bootloader vor ein paar Wochen belächelt... "Das ist ja so als ob der Windows-NT Server beim kopieren von Dateien eine grafische Animation bekommt..." [Wer alt genug ist kann das verstehen])

Ich hab mir mal Text zusammengeschrieben fürs Wiki, und würde diesen später veröffentlichen. Geflasht habe ich den Bootloader wie gewohnt, weil das am einfachsten ist (wenn man es kennt).



Zu der Bootloader-Tauschmethode mittels Arduino Sketch: Sehe ich das richtig ?
-Ich brauche eine Arduino IDE mit SAM und STMDuino Erweiterungen auf z.B. siehe hier: https://www.heise.de/developer/artikel/Keine-bittere-Pille-die-Blue-Pill-mit-ARM-Cortex-M3-4009580.html
-Dann muss man wohl noch für einen Treiber sorgen mittels der Skript von STM-Duino...
-Ich wähle als Board Maple-Mini mit Original Bootloader, 72 Mhz, smallest
-wähle den Port vomn FTDI-Adapter
-verkable diesen wie zum bisherigen Bootloader-Flashen
Wäre das der Weg ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 29 August 2019, 12:42:59
Ich kenne es so das man den Maple mini mit Original Bootloader direkt mit USB am PC anschließt und ihn dann mit Arduino flashen kann. Also so wie auch einen Arduino UNO z.B. da braucht man keinen FTDI für. Hab das mit diesem Bootloader aber noch nicht getestet.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 29 August 2019, 13:21:23
Zitat von: Ranseyer am 29 August 2019, 12:13:10
Danke für den Input. (Ich hatte den MSC-Bootloader vor ein paar Wochen belächelt... "Das ist ja so als ob der Windows-NT Server beim kopieren von Dateien eine grafische Animation bekommt..." [Wer alt genug ist kann das verstehen])

Ich hab mir mal Text zusammengeschrieben fürs Wiki, und würde diesen später veröffentlichen. Geflasht habe ich den Bootloader wie gewohnt, weil das am einfachsten ist (wenn man es kennt).



Zu der Bootloader-Tauschmethode mittels Arduino Sketch: Sehe ich das richtig ?
-Ich brauche eine Arduino IDE mit SAM und STMDuino Erweiterungen auf z.B. siehe hier: https://www.heise.de/developer/artikel/Keine-bittere-Pille-die-Blue-Pill-mit-ARM-Cortex-M3-4009580.html
-Dann muss man wohl noch für einen Treiber sorgen mittels der Skript von STM-Duino...
-Ich wähle als Board Maple-Mini mit Original Bootloader, 72 Mhz, smallest
-wähle den Port vomn FTDI-Adapter
-verkable diesen wie zum bisherigen Bootloader-Flashen
Wäre das der Weg ?
Wenn das ins Wiki kommt (und ein ordentlicher und einfacher Weg ist für Bootloader und image flashen auf vielen Systemen) dann wäre ich aber stark dafür den Rest gleich aus dem Wiki zu nehmen. Also das flashen BL mit TTL und ohne sowie den Teil mit dfu-util.
Sonst hat der User wieder x Möglichkeiten und weiss nicht welche er nehmen sol
Just my 2ct
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 29 August 2019, 13:51:11
Wenn auf dem Maple Mini schon ein DFU Bootloader vorhanden ist braucht man keinen FTDI Adapter für den Update Sketch.

Die STMDuino Erweiterung muss installiert sein und die Bootloader Version muss in der IDE angegeben werden (Original oder Bootloader 2.0). Und wenn bereits die aculfw auf dem Maple Mini geflasht ist, muss man noch manuell den Reset am Maple Mini betätigen sobald "Resetting to bootloader via DTR pulse" beim hochladen im Ausgabebereich der IDE angezeigt wird.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 29 August 2019, 14:35:36
ZitatWenn auf dem Maple Mini schon ein DFU Bootloader vorhanden ist braucht man keinen FTDI Adapter für den Update Sketch.

OK, du wählst an der Stelle dann aber einen seriellen Port aus. (Aber ich bekomme keinen angeboten nach der folgenden Aktion:)
ZitatPlease open a cmd window (run as administrator), navigate to the folder: /drivers/win/ and run: install_drivers.bat. Note: This doesn't actually install drivers. Windows comes pre-installed with a compatible Serial USB driver and a DFU (upload) driver. However the built in drivers need to be associated with the USB ID of the Maple serial and DFU devices. The batch file and wdi-simple.exe do the clever stuff to convince Windows 7 or newer, that it should use its drivers with the Maple serial and DFU devices.

Grund könnte sein, dass bei mir per LibUSB direkt ein MAPLE-DFU Gerät erkannt wird...

=> Fazit den Part finde ich frickelig und keinesfalls so richtig unter Windows. Ich schau mir das nachher nochmals unter Linux an. Da sollte das alles einfacher sein...



edit: Z.B. Mittels Zadig kann ich den Treiber umbiegen auf USB-Serial (CDC), dann kann ich auch einen Port in der IDE angeben. Aber es mein Maple hat PID "0004" und erwartet wird jedoch "0003"...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 29 August 2019, 19:05:04
Zitat von: Ranseyer am 29 August 2019, 14:35:36
OK, du wählst an der Stelle dann aber einen seriellen Port aus. (Aber ich bekomme keinen angeboten nach der folgenden Aktion:)
Grund könnte sein, dass bei mir per LibUSB direkt ein MAPLE-DFU Gerät erkannt wird...
Verwendest du einen neuen Maple Mini auf dem nur der Bootloader drauf ist? Solange da kein Programm raufgeladen wurde bleibt der Bootloader im DFU Mode. Dann muss man auch keinen COM Port in der IDE auswählen. Es wird beim flashen ja ein Gerät im DFU Mode erwartet und dann verwendet.

Und hast du eventuell schon früher mal mit dem Zadig Tool den Treiber für den Maple verbogen? Normalerweise braucht man das hier nicht.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 06 September 2019, 14:15:06
Mahlzeit zusammen,

In meiner Verzweiflung muss ich mich noch mal an euch wenden.
Ich habe 2 mapleCUN's (1x Large, 1x small von Ranseyer Platinen) bestückt und beide empfangen und senden.
Mit einfachem Empfangen von 433 MHz habe ich keine Probleme.
Für 868 nutze ich MAX.
Da ich vor kurzem ein Thermostat austauschen musste, ist mir aufgefallen, dass das ACK mit dem Maple nicht klappt. Mit beiden nicht.
Auf beiden ist die aktuellste a-culfw drauf. Tests mit älteren Versionen von a-culfw waren auch nicht erfolgreich.
Ich habe dann mal meinen nanoCUL entstaubt und dort klappt es problemlos.
Die HTs werden in fhem problemlos erkannt und per autocreate angelegt, allerdings zeigt der HT kein AC an beim pairing und im Log kommen dann immer Meldungen mit "missing ACK".

CUL_MAX_SendQueueHandler: Missing ack from 18b264 for 0f01040312345618b264001306038b70


Ich sehe im Log auch die Meldung mit dem PairPing

2019.09.06 08:29:15 4:  CUL_Parse: mapleCUN1 Z17000000165824000000001001A04E455130363730363339EB -84.5
2019.09.06 08:29:15 5:  mapleCUN1: dispatch Z17000000165824000000001001A04E455130363730363339
2019.09.06 08:29:15 5:  CUL_MAX_Parse: len 23, msgcnt 00, msgflag 00, msgTypeRaw PairPing, src 165824, dst 000000, groupid 0, payload 1001A04E455130363730363339
2019.09.06 08:29:15 5:  CUL_MAX_Parse: rssi: -84.5
2019.09.06 08:29:15 5:  CUL_MAX_Parse: Got PairPing (dst 000000, pairmode 0), firmware 16, type 1, testresult 160, serial NEQ0670639
2019.09.06 08:29:15 3:  CUL_MAX_Parse: Pairing device 165824 of type HeatingThermostat with serial NEQ0670639

Ändern einer Temperatur geht auch, allerdings frisst das halt schnell die Credits auf, da er immer wieder sendet, weil er kein ACK bekommt vom HT.
Hat zufällig jemand noch eine Idee, wo ich ansetzen kann?
Ich will ungern für den kommenden Winter wieder Pi's entstauben und mit nanoCULs meine HT steuern.

Gruß
Maui
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 06 September 2019, 15:24:39
Ein RSSI von -84.5 ist nicht wirklich gut. Wie weit sind der MapleCUN und Thermostat voneinander entfernt? Und wie ist der RSSI beim nanoCUL?

Hast du eventuell ein schlechtes CC1101 Modul verbaut: https://forum.fhem.de/index.php/topic,91740.0.html (https://forum.fhem.de/index.php/topic,91740.0.html)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 06 September 2019, 17:49:40
Hallo

Ich habe nun mein Maple fertig und auch im Gehäuse.
Nun habe ich ihn per Lan Modul 5500 ans Netzwerk angeschlossen.
Vorher war er per USB mit einem Banana Pi verbunden und alles war OK.
Jetzt hat er bei  Modul 3 und 4 nur Opend in FHEM stehen.

Cun1 habe ich per Lan verbunden und auch die Stack´s sind da. bzw Defined.

Wie bekomme ich die 2 Cun´s wieder mit Initialized zum laufen ?


Grüße André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: gloob am 06 September 2019, 18:07:59
Zitat von: rieders am 06 September 2019, 17:49:40
Hallo

Ich habe nun mein Maple fertig und auch im Gehäuse.
Nun habe ich ihn per Lan Modul 5500 ans Netzwerk angeschlossen.
Vorher war er per USB mit einem Banana Pi verbunden und alles war OK.
Jetzt hat er bei  Modul 3 und 4 nur Opend in FHEM stehen.

Cun1 habe ich per Lan verbunden und auch die Stack´s sind da. bzw Defined.

Wie bekomme ich die 2 Cun´s wieder mit Initialized zum laufen ?


Grüße André

Zeig doch mal deine FHEM Definitionen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 06 September 2019, 18:19:15
Ich habe jetzt die 2 Stack´s entfernt und dann auch die Cun´s.
Danach alles wie im Wiki beschrieben neu erstellt.
Jetzt ist wieder alle OK.


Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 06 September 2019, 19:30:04
Wenn derartige Probleme wieder auftreten dann nutz mal STACKABLE_CC statt STACKABLE. Im Wiki steht wie das da geht. STACKABLE_CC verursacht öfter derartige Probleme.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 07 September 2019, 13:26:11
Zitat von: Telekatz am 06 September 2019, 15:24:39
Ein RSSI von -84.5 ist nicht wirklich gut. Wie weit sind der MapleCUN und Thermostat voneinander entfernt? Und wie ist der RSSI beim nanoCUL?

Hast du eventuell ein schlechtes CC1101 Modul verbaut: https://forum.fhem.de/index.php/topic,91740.0.html (https://forum.fhem.de/index.php/topic,91740.0.html)
Danke für den Tipp. Könnten wirklich defekte Module sein.
Ich habe jetzt mal neue bestellt. Hoffe die laufen besser.

Gruß
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 07 September 2019, 15:45:34
Ich habe jetzt das Problem, das Fhem nach einigen Stunden nicht mehr erreichbar ist.
Das hängt wahrscheinlich mit dem Maple zusammen.

Ich habe mal ein Auszug auf dem Log

2019.09.07 15:23:50 2: ESPEasy ESPEasy_192.168.1.103_49759: No basic authentication active but credentials received
2019.09.07 15:23:52 3: MAPLECUL2_433 IT_set: IT_FFFF0F0FFF off
2019.09.07 15:17:14 1: Including fhem.cfg
2019.09.07 15:17:18 3: WEB: port 8083 opened
2019.09.07 15:17:19 2: eventTypes: loaded 3484 events from ./log/eventTypes.txt
2019.09.07 15:38:06 3: Mi_Vacuum: initialized, using Rijndael

Irgendwie stimmt doch da was nicht mit der Logzeit?

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 12 September 2019, 16:45:09
Hallo

Ich hatte jetzt den Cul einige Tage laufen.
Nachdem ich ihn auf STACKABLE_CC neu in FHEM eingebunden hatte verhält sich das Teil eigenartig.
Die Frequenzen der einzelnen Module sind jetzt irgenwie durcheinander.
V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) MapleCUNx4_8F (F-Band: 433MHz) hat zB Modus 3. Was eigentlich ein 868 Modul ist.
Wenn ich mit 433 ein Schalter betätige kann ich keine Revolt Daten mehr empfangen.

Kann ich den Maple auf "Werkseinstellung" zurücksetzen ?

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 12 September 2019, 16:53:41
Ja. Schau dringend mal ins Wiki.
Ich habe es reingeschrieben, damit ich mir das nicht merken muss.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 12 September 2019, 16:59:18
Vielen Dank Ranseyer

set CUL1 raw e

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 13 September 2019, 14:27:01
Hallo

Also irgendwie habe ich schlechten Empfang mit dem 433 MHZ Modul, der liegt bei -79 db.
Antenne ist dran.

ccconf
freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB

Und dann kann er Daten nicht auswerten zB.
2019-09-13 14:23:13 STACKABLE_CC mapleCUN2 UNKNOWNCODE P12#75E746B508BEA2232F

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: carpenoctem am 14 Oktober 2019, 16:09:25
Moin,

einmal eine Frage zum mapleCUN:

Hat noch jemand das Problem, dass zum einen nach dem Reboot von FHEM der WMBUS_T Empfang nicht Funktioniert oder er nach n Stunden (8-40h bis jetzt) sporadisch aufhört?
Ein reopen ausführen, auf MAX und wieder auf WMBUS_T wechseln oder einfach als RAW den Init Befehl für WMBUS_T reicht bei mir zumindest das Problem zu beheben.

Im CUL Bereich gibts dazu nun ein Thema: https://forum.fhem.de/index.php/topic,84504.15.html (https://forum.fhem.de/index.php/topic,84504.15.html)
Da ich aber nicht weiß, ob es ein CUL oder ein mapleCUN Spezifisches Problem ist, wollte ich hier mal nachfragen: Hat noch jemand solche Probleme oder sowas beobachtet?

Grüße
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 24 November 2019, 06:43:52
Hallo

Ich habe auch das Problem das ich nach dem Täglichen Neustart von Fhem keine wm-Bus Daten mehr empfange.
Wenn ich den betreffenden cun von Wmbus-s auf wmbus-t setze und dann wieder zurück , läuft es wieder einige Stunden,  bzw. bis zum Neustart.
Ich denke da da noch ein Bug in der Firmware ist.
Das ist die Firmware die ich benutze    
V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53)

Grüße
André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ich79 am 21 Januar 2020, 19:25:15
Hi zusammen!
Ich habe einen gebrauchten MapleCUN erstanden und möchte eine neue a-culfw drauf spielen, weil ich auch WM-Bus nutzen möchte. Es haben sich aber bei mir zwei Probleme herausgestellt.

Wäre über Tips dankbar!
Danke und viele Grüße
Boris
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 21 Januar 2020, 19:39:38
Hi Boris,

ohne genaues zu wissen sieht die Bestückung aus wie einer von den MapleCUN die ich verkauft habe. Falls das so ist brauchst du zum updaten keine knöpfe drücken. Du musst das Script ausführen zu flashen das in einer schleife ständig probiert einen angeschlossenen MapleCUN zu finden. Dann schließt du einfach das USB Kabel an und er flasht die neue firmware. Du brauchst die noch nicht mal selbst bauen da es die auch schon fertig gibt.

#! /bin/sh
while (true); do

sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download ~/MapleCUNx4_W5500_BL.bin
if [ $? -eq 0 ]
then break
fi
sleep 1
done
exit


PS: Die Buttons Reset und But32 sind übrigends unter den 2 löchern in der Leiterplatte so das man die mit einem dünnen Gegenstand (z.B. eine spitze Pinzette) drücken kann.

LG Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 21 Januar 2020, 20:00:19
Das skript braucht man aber auch gar nicht. Einfach nach dem anstecken innerhalb von 1s auf Enter drücken und dann flasht er auch brav, natürlich muss dfu-util mit richtigen Optionen vorausgewählt sein als Befehl.

Was läuft denn aktuell auf maple? A-culfw?
Der bootloader wird ja dann schon geflasht sein
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 21 Januar 2020, 20:07:57
Zitat von: Eistee am 21 Januar 2020, 19:39:38
PS: Die Buttons Reset und But32 sind übrigends unter den 2 löchern in der Leiterplatte so das man die mit einem dünnen Gegenstand (z.B. eine spitze Pinzette) drücken kann.


Lustige Idee aufgrund deines Fotos: Ich könnte die Löcher in Zukunft ja auch mal beschriften...
Danke für den indirekten Anstoss...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 21 Januar 2020, 20:25:54
Und einen kleinen Tick großer machen. Den Reset kann man meist nur sehr schlecht drucken da er leicht versetzt ist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ich79 am 21 Januar 2020, 21:07:21
Zitat von: Eistee am 21 Januar 2020, 19:39:38
ohne genaues zu wissen sieht die Bestückung aus wie einer von den MapleCUN die ich verkauft habe. Falls das so ist brauchst du zum updaten keine knöpfe drücken. Du musst das Script ausführen zu flashen das in einer schleife ständig probiert einen angeschlossenen MapleCUN zu finden. Dann schließt du einfach das USB Kabel an und er flasht die neue firmware. Du brauchst die noch nicht mal selbst bauen da es die auch schon fertig gibt.
Jau, ich glaube auch, dass das einer von Dir ist.

Zitat von: Eistee am 21 Januar 2020, 19:39:38
PS: Die Buttons Reset und But32 sind übrigends unter den 2 löchern in der Leiterplatte so das man die mit einem dünnen Gegenstand (z.B. eine spitze Pinzette) drücken kann.
Ich habe bestimmt 10 Minuten auf das Ding geschaut, um die Platinenversion rauszufinden. Aber die Löcher sind mir niemals aufgefallen! Das ist echt mal eine schlaue Idee! Hatte die ganze Zeit nach irgendwelchen Lötpads mit Beschriftung Ausschau gehalten... Werde ich morgen Abend gleich versuchen.

Danke an alle! Das Forum ist echt super :)
VG
Boris
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 21 Januar 2020, 22:28:46
ZitatAber die Löcher sind mir niemals aufgefallen! Das ist echt mal eine schlaue Idee!
Danke !

(Andererseits: Ohne die Löcher wäre das Design ziemlich dumm :-) )

PS: Doku vor der V4: https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/Archiv
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 02 Februar 2020, 14:05:49
Hi,

habe gerade wieder ein seltsames Problem.
Vielleicht hat einer eine schnelle Antwort für mich.

Ich baue auf einem Raspberry den ich vor kurzem auf Buster geupdated habe.

Habe git ganz neu ausgechecked.

make clean
make

Der Build läuft durch.
Die bin Files sind danach 59 KB groß.

Flashe ich diese mit:
dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin

Flash geht auch  durch.

Bekomme ich aber kein Device mit:
ls /dev/serial/by-id/

Nehme ich das Binary File das hier zur Verfügung gestellt wird und flashe es genauso, geht es.
Mir fällt auf, dass das binary file 66KB groß ist.

Jemand eine Idee?

Danke und gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 02 Februar 2020, 17:17:24
Nabend zusammen.
Hat zufällig schon jmd ein case für ranseyers small 2.0 (3 fach CUN) Platine designt?
Sonst würde ich mal was basteln zum drucken.

Gruß
Maui
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 Februar 2020, 17:48:47
...Platine hast du schon ? ((sonst würde ich dich unterstützen!))

Ich bin dann einer der ersten der sich das Ganze druckt...

PS: Auf meinem Musterfoto ist der Maple dümmlich verbaut... (Grund: der war schon bestückt. Ich würde den künftig unter die Platine verlegen, mit der USB Buchse in der Aussparung der Platine, also die Anschlüsse gespiegelt in V2.1)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 02 Februar 2020, 17:53:04
Ja hab ich schon, von dir.
Ich hab deine fotos gesehen (und hatte dich auch gefragt).
Habe jetzt das lan modul auf einer Seite und den maple auf der anderen.
Aber dazu musste ich ihn drehen und nun ist der usb anschluss nicht in der Aussparung.
Das meinst du aber wohl mit v2.1.

Dann werde ich nächste Woche mal schauen was ich gebastelt kriege.
Wird aber eher kantiger und zweckmäßig werden mein Design  ;D
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 02 Februar 2020, 17:55:40
ZitatAber dazu musste ich ihn drehen und nun ist der usb anschluss nicht in der Aussparung.
Das meinst du aber wohl mit v2.1.

Ja genau... Ich sollte eine V2.1 entwickeln wie beschrieben, aber der Platzbedarf sinkt sollte das dann ja auch in dein Gehäuse passen...

(Nur ist mein Muster vermutlich an der LAN Buchse 10mm höher als dein Exemplar...  :'( )
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 02 Februar 2020, 17:59:56
Zitat von: stefanru am 02 Februar 2020, 14:05:49
Jemand eine Idee?
Ich schätze mal, dass die GCC Version zu neu ist. Für den MapleCUN sollte die GCC Version 5.4.1 verwendet werden.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: stefanru am 02 Februar 2020, 18:07:17
Danke Telekatz,


gcc --version
gcc (Raspbian 8.3.0-6+rpi1) 8.3.0


Dann mach ich mal nen downgrade.

Gruß,
Stefan
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 02 Februar 2020, 19:05:11
Zitat von: Ranseyer am 02 Februar 2020, 17:55:40
(Nur ist mein Muster vermutlich an der LAN Buchse 10mm höher als dein Exemplar...  :'( )
Naja aber das lässt sich ja variabel halten bzw in mehreren Höhen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 03 Februar 2020, 15:06:16
Ich hab mal was minimalistisches gebastelt.
Löcher für die SMA Antennen müssen gebohrt werden und die Höhe ist bewusst ein bisschen großzügig gewählt.
Meine Hauptziele (weniger anfällig für Kleinkinder und der Schlafbesuch wird nicht vom blauen Blinken genervt) sind damit aber eingefangen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ralf9 am 09 April 2020, 21:53:55
Für diejenigen, denen auch zwei cc1101 ausreichend sind, gibt es inzwischen eine kleinere Variante den MapleSDuino
https://forum.fhem.de/index.php/topic,106278.0.html
https://forum.fhem.de/index.php/topic,109220.15.html

Inwischen gibts dafür auch die a-culfw firmware.
Ist es normal,daß das compilieren nicht so einfach ist und nur mit einer älteren gcc Version funktioniert.
https://forum.fhem.de/index.php/topic,106278.msg1037755.html#msg1037755
https://forum.fhem.de/index.php/topic,106278.msg1037726.html#msg1037726

Im MapleCul Wiki steht, daß für die a-culfw der Bootloader2.0 erforderlich ist, gibt es einen besonderen Grund warum der Orginal Bootloader nicht ausreichend ist?

Gruß Ralf
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: RaspiLED am 10 April 2020, 10:53:28
Hi Ralf,
ich bin nicht der Super Experte, aber mein Verständnis wäre das der neue Bootloader mehr Speicher für die Programme bietet.

Das wiederum resultiert in unterschiedlichen Programmplätzen beim booten. ID1 0x8005000 bzw. ID2 0x8002000 für 20k RAM/120k Flash statt user code area ID0 0x8000800 bei 17k RAM/108k Flash.

,,The Maple Mini original bootloader supports 2 upload modes, selected by the uploader program with a parameter called Upload ID. Upload ID=0 uploads to RAM. (This option has been modified so that it returns an error if used - more details below) Upload ID=1 uploads to Flash. It uploads sketches to 0x8005000, thus reserving the initial 20KB of the flash memory for itself. It also reserves the initial 3KB of ram, so sketches can use up to 17KB.

We added a new upload mode.

Upload ID=2 uploads to Flash. It uploads sketches to 0x8002000, thus reserving the initial 8KB of the flash memory for itself. ,,


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 April 2020, 10:57:56
Ja, das ist normal, dass es mit neueren GCC Versionen nicht funktioniert. Da gibt es dann Probleme mit der Optimierung des GCC.

Den Bootlader 2.0 habe ich genommen, weil er kleiner ist als der original Bootloader. Und schneller war er auch noch.

Es muss aber nicht der Bootloader 2.0 sein. Es geht auch ein anderer Bootloader, solange er maximal 8k groß ist, da die a-culfw auf die Startadresse 0x8002000 gelinkt ist. Für den MapleCUN habe ich einen MSC Bootloader (https://github.com/Telekatz/MSC-stm32f103-bootloader/releases) erstellt, der für den Endanwender einfacher zu verwenden ist als ein DFU Bootloader. Es wird kein zusätzliches Programm zum flashen benötigt. Mit dem muss man nur die .bin Datei auf das vom Bootloader bereitgestellte USB Laufwerk kopieren.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 10 April 2020, 11:00:39
Hallo RaspiLED,

diese Info  (https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader)war hilfreich, da die Funktion der Upload-Modus 1 oder 2 bisher nur durch Ausprobieren der Einstellungen herauszubekommen war.
Der reine Bootloader ohne Seriellen-Sketch, der die 3 COM-Schnittstellen öffnet ist mit 7KB durchaus als schlank zu bezeichnen.
Allerdings hat Arduino  die Adresse 0x8005000 fest im Linker eingestellt. 
Müsste man im Make-Skript mit berücksichtigen, wenn man das einstellbar machen möchte.

Grüße,
Jürgen

/edit: Telekatz war schneller ;-)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 April 2020, 11:16:47
Wenn du in der Arduino IDE den Bootloader 2.0 auswählst, wird das Programm auch auf die Adresse 0x08002000 gelinkt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 10 April 2020, 11:19:10
Zitat von: Telekatz am 10 April 2020, 11:16:47
Wenn du in der Arduino IDE den Bootloader 2.0 auswählst, wird das Programm auch auf die Adresse 0x08002000 gelinkt.

... und überschreibt im "falschen" Bootloader (der mit dem implementierten UART-Sketch mit 23KB und 20 im Namen) dann diesen ....  ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 April 2020, 11:25:44
Welcher soll der "falsche" Bootloader sein?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 10 April 2020, 11:32:38
Dieser: https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/binaries/maple_mini_boot20.bin

http://blog.lincomatic.com/wp-content/uploads/2015/10/selectbootloader.jpg (http://blog.lincomatic.com/wp-content/uploads/2015/10/selectbootloader.jpg)

... wollte aber keine neue BL-Diskussion  ;)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 April 2020, 11:43:26
Da ist der Bootloader 2.0 mit 8k. Wo soll da ein Problem sein. Wenn du mit diesem Bootloader ein Sketch flashst, dann sorgt doch das neue Sketch dafür, dass eine UART Schnittstelle bereitgestellt wird. Das ist auch beim original Bootloader genauso. Kein Bootloder stellt eine UART Schnittstelle bereit. Das macht immer das Sketch. Die Bootloader implementieren nur die USB DFU Klasse.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ralf9 am 10 April 2020, 12:15:51
ZitatJa, das ist normal, dass es mit neueren GCC Versionen nicht funktioniert. Da gibt es dann Probleme mit der Optimierung des GCC.
Weißt Du zufällig ab welcher GCC Version es Probleme mit der Optimierung gibt?
Wenn dies dann z.B. hier in der ersten Nachricht oder im Wiki stehen würde, könnte dies dann evtl einigen ersparen beim compielieren dieses Problem zu bekommen.

Der orginal Bootloader ist demnach größer als  8k.
Bei der Arduino IDE steht bei der Upload Methode 1: Orginal (17K RAM..), bedeutet dies dann, daß der Orginal Bootloader 3K RAM fest für sich reserviert?
Sind es auch nur 17K RAM, wenn beim Bootloader 2.0 die Upload Methode 1 verwendet wird?

Gruß Ralf
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 10 April 2020, 12:54:06
Die letzte GCC Version, mit der es funktioniert, ist 5.4. Die ist auch im culfw@ARM (https://forum.fhem.de/index.php/topic,38404.0.html) Thread angegeben.

Zitat von: Ralf9 am 10 April 2020, 12:15:51
Der orginal Bootloader ist demnach größer als  8k.
Bei der Arduino IDE steht bei der Upload Methode 1: Orginal (17K RAM..), bedeutet dies dann, daß der Orginal Bootloader 3K RAM fest für sich reserviert?
Sind es auch nur 17K RAM, wenn beim Bootloader 2.0 die Upload Methode 1 verwendet wird?
So sieht es wohl aus. Allerdings ist die Upload Methode 1 auch nur für die Programme sinnvoll, die bereits für den original Bootloader kompiliert sind. Der Bootoader ist damit abwärtskompatibel.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 05 Mai 2020, 21:39:26
Hallo zusammen,
wie mache ich denn am einfachsten ein Update für mienen Maplecun?
Das Script funktioniert bei mir nicht:

#! /bin/sh
while (true); do

sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download ~/MapleCUNx4_W5500_BL.bin
if [ $? -eq 0 ]
then break
fi
sleep 1
done
exit


dfu-util: Could not open file /home/pi/MapleCUNx4_W5500_BL.bin for reading: No such file or directory

Kann da jemand weiterhelfen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 05 Mai 2020, 21:46:15
Einfach das Script so anpassen dass eine Firmware gefunden wird. Oder die Firmware anpassen. Oder ohne Script machen und schnell sein.

Also das hier:
Zitat~/MapleCUNx4_W5500_BL.bin
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 07 Mai 2020, 06:40:14
Danke habe ihn upgedatet, hat mein Problem aber auch nicht gelöst.
Benutzt irgendjemand den maplecun mit WMBus?
Bei mir empfängt er immer nur einmal daten und dann erst wieder nach einem komplettreboot.
Welcher der 4 cc1101 ist für WMBus am besten geeignet?
Gruß
Matthias
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 07 Mai 2020, 11:05:53
Hast du einem der CC Transceiver den entsprechenden rfmode zugeordnet?
set <name> rfmode WMBus_x
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: matthias soll am 07 Mai 2020, 11:29:34
Ja habe ich:
define MAPLECUL1_868 CUL /dev/serial/by-id/usb-STM32_MapleCUL_470e44a3-if00@38400 4444
setuuid MAPLECUL1_868 5dfb692d-f33f-bbdb-81ab-0da8e5d98a54fa88
attr MAPLECUL1_868 group Gateways
attr MAPLECUL1_868 icon cul_868
attr MAPLECUL1_868 model CUN
attr MAPLECUL1_868 rfmode WMBus_T
attr MAPLECUL1_868 room TRX

Interessant ist, dass es einmal empfangen wird und dann nichts mehr bis man komplett neu bootet:
2020-05-06_22:32:23 TechemWasser listening
2020-05-06_22:32:23 TechemWasser TechemWassero: 11.4
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dirk_neujahr@freenet.de am 20 Juni 2020, 20:31:29
Hallo !
Darf ich mich hier mal einklinken ?
Hab hier einen Maple Mini mit 1x433/1x868-CC1101, der nicht mehr funktionieren möchte. Hatte den zu Anfang in FHEM laufen, hat auch gut geklappt. Bilder von dem Teil sind angehängt.
Als er frisch gekauft war, war die a-culfw 1.26.08 für beide CC1101 installiert und er hat auch brav seine Dienste getan.
Hab ihn wahrscheinlich selbst durch ne falsche Firmware dazu gebracht, dass er nur noch zu Anfang ein paarmal blinkt, danach bleibt die LED aber aus.
Egal, welcher Modus des MapleMini, es erscheint keine serielle Verbindung.

Meldung von dfu-util nach normalem Anstecken an USB:
Found DFU: [1eaf:0003] ver=0201, devnum=49, cfg=1, intf=0, path="20-1.4.3", alt=2, name="UNKNOWN", serial="UNKNOWN"
Found DFU: [1eaf:0003] ver=0201, devnum=49, cfg=1, intf=0, path="20-1.4.3", alt=1, name="UNKNOWN", serial="UNKNOWN"
Found DFU: [1eaf:0003] ver=0201, devnum=49, cfg=1, intf=0, path="20-1.4.3", alt=0, name="UNKNOWN", serial="UNKNOWN"

Meldung von dfu-util nach Aktivieren Bootloader-Modus:
Found DFU: [1eaf:0003] ver=0201, devnum=51, cfg=1, intf=0, path="20-1.4.3", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=51, cfg=1, intf=0, path="20-1.4.3", alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=51, cfg=1, intf=0, path="20-1.4.3", alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"

Hab es schon mit der MapleCUNx4_W5500_BL.bin versucht, nach Blinken beim Booten danach keine LED-Aktivität mehr. Auch die Maple_cul_USB_411dev200611.bin
oder Maple_sduino_USB_411dev200611.bin brachten keine Besserung.
Kann mir jemand sagen, welche a-culfw/signalduino auf diesen Stick aufgespielt werden muss, damit der wieder funktioniert ? Und wie wird diese Datei aufgespielt ? dfu-util oder avrdude ? Und wenn dann das ganze noch am Mac zu bearbeiten ginge, wäre das ein Traum.
Oder man kann das Ganze am Raspi wieder zum Leben erwecken ?

VG Dirk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 20 Juni 2020, 21:15:16
Falls du das Teil von Smarthome-Komponete.de (Oder so ähnlich) hast solltest du den nach einer Firmware fragen...

Keine Ahnung wie seine HW genau gestrickt ist. (Bootloader= ???)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dirk_neujahr@freenet.de am 21 Juni 2020, 15:49:46
Hallo !
Danke für den Tip, gemacht und eine Antwort erhalten:
MapleCUNx4_W5500_BL.bin war die richtige und der Stick läuft wieder !
Trotzdem danke an euch !

VG Dirk
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: djfflow am 22 Juni 2020, 21:16:17
Hallo,
ich bin gerade am verzweifeln.
Ich habe mir einen MapleMini gekauft und ein W5500 sowie ein CC1101 (433) Modul.
Wollte nun wie in der Anleitung beschrieben ist, den Bootloader flashen (https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen_ohne_TTL-Adapter (https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen_ohne_TTL-Adapter)). Das hat dann irgendwann auch geklappt. Habe dann das Beispiel der Arduino IDE BlinkwithoutDelay hochgeladen und das klappte auch (LED blinkt im angegebenen Interval).
Nun wollte ich gerne die a-culfw drauf ziehen. Aber weder über die Schritte für DFU-Bootloader noch die Schritte für MCS Bootloader kann ich die MapleCUNx4_W5500_BL.bin übertragen.
Was habe ich falsch gemacht? Was kann ich tun das ich die a-culfw übertragen bekommen?

MfG
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: PeMue am 22 Juni 2020, 21:46:13
Bitte poste mal, was auf der seriellen Schnittstelle ausgegeben wird.

Gruß Peter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 23 Juni 2020, 10:33:01
Zitat von: djfflow am 22 Juni 2020, 21:16:17
Was habe ich falsch gemacht? Was kann ich tun das ich die a-culfw übertragen bekommen?


Timing ? Knöpfe nur "fast richtig" gedrückt...

Natürlich ist das absolut unnötig: https://wiki.fhem.de/wiki/MapleCUN#Trick_zum_USB-Flashen_.28Code_Schnipsel_f.C3.BCr_kleines_Skript.29
Aber bei mir funktioniert es sehr gut und es gibt dir die richtigen Hinweise. (Achtung: das ist nicht für den MSC Bootloader)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: djfflow am 23 Juni 2020, 21:23:31
Ok. Hab es nun hinbekommen die Firmware zu flashen. mit der richtigen Knopf-Drück-Reihenfolge.
Ich habe wie schon geschrieben ein Lan Modul und ein 433Mhz Modul dran. Kann ich irgendwie prüfen, ob die Verkabelung korrekt ist?
Mit sind im Eifer des Gefecht leider die Kontakt-Stifte des 433 Moduls an die metallerne Verkleidung des LAN Moduls gekommen (während Strom drauf war  :-[ ), daher bin ich mir unschlüssig ob die Module überhaupt noch funktionieren.
Wenn ich den Stick an den PC hänge bekomme ich 3 COM Ports angezeigt. Welcher ist welcher und wie muss ich das dann in FHEM konfigurieren?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 23 Juni 2020, 21:45:44
-Wiki
-Wiki
-Wiki
...

Lies dich dort doch mal ein. Mit einer alten Firware bekommst du auf dem Debug Port entsprechende Ausgaben, z.B.  ob das 433MHz Modul erkannt wurde.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 23 Juni 2020, 21:58:48
Ich würde mir mal wünschen das man die Debugausgaben mit einem Befehl An und Aus schalten kann und diese Einstellung mit ps auch im Eprom speicherbar ist. Die Debugausgaben könnte man ja mit einem speziellen Prefix senden der das CUL Modul in FHEM nicht behindert z.B. ein # Zeichen am Zeilenanfang. Ich arbeite momentan auch immer mit zwei Firmwares. Erst wird mit der "Debug" Firmware geprüft ob die Verkabelung funktioniert und dann mit der richtigen Firmware die Funktion des MapleCUN.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: djfflow am 24 Juni 2020, 10:40:24
Hallo,
habe das Wiki soweit gelesen genauso grob diesen Thread. Aber ich habe noch offene Fragen.
ich habe nun mir eine alte Firmware (1.25.01) besorgt und diese per dfu-util (dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin) geflasht. Die blaue LED vom Maple Mini blinkt im ca. Sekundentakt. Ist das so korrekt?
Ich lese immer von Debugport, finde aber nicht so recht wo dieser sein soll.
Ich hatte versucht den Maple per USB mit dem PC zu verbinden und dann mit dem ersten der 3 Com Ports mit 115200 baud eine Verbindung herzustellen. Aber wenn ich irgendetwas eingebe oder so bekomme ich überhaupt keine Ausgabe. Daher vermute ich mal ich brauche einen USB Seriell Adapter. An welche Pins muss dieser angeschlossen werden? Ist TX1 und RX1 also Pin 25 & 26 korrekt?
Gruß
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 24 Juni 2020, 21:51:44
Für den Debugport braucht man einen USB Wandler. Belegung siehe Schaltplan im ersten Beitrag.

Windows vergibt die COM Ports auch nicht unbedingt in aufsteigender Reihenfolge. Entweder alle durchprobieren oder im Gerätemanager das USB-Gerät mit der Harware-ID USB\VID_0483&PID5743&MI_00 suchen.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ralf9 am 03 Juli 2020, 17:46:13
Hallo,

ich habe für das MapleCun- Wiki einen Änderungsvorschlag:
Bei "Bootloader flashen mit TTL-Adapter" steht nur die Windowsvariante.
Für Linux steht es weiter unten bei "Firmware flashen"
Ich würde es besser finden, wenn das "stm32flash" für Linux auch bei "Bootloader flashen mit TTL-Adapter" stehen würde.

Gruß Ralf
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: killah78 am 09 August 2020, 21:40:20
Hi,
kann mir jemand mein Phänomen erklären?
Ich habe den Maple CUL mit 3 CC. 1. auf 868, 2. auf 433 und 3. auf 868.

Den ersten habe ich ganz normal als CUL defniert auf das USB device selbst.
Den zweiten und dritten dann als Stackable_CC.

Mein Phänomen ist aber, dass der erste den gleichen Emfang hat wie der zweite, aber mit einem vorausgestellten "*". Eigentlich heißt das ja, dass das für das zweite Modul ist. Warum wird mir das beim ersten Modul angezeigt? Fehlt mir hier noch eine Einstellung? Das zweite und dritte Modul tun ihren Dienst wie sie sollen.

Oder ist das normal, dass diese Einträge in RAWMSG erscheinen?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 09 August 2020, 22:03:11
Ist normal da das erste Modul ja die Nachrichten an die nachfolgenden Module weiter leitet.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kadettilac89 am 13 September 2020, 21:57:48
Hallo,

ich versuche den MapleCUN mit ESP-01 zum Laufen zu kriegen.

MapleCUN per USB wird erkannt, siehe List unten. Ich habe auf dem ESP-01 ESP-Link geflasht (3 Stück). Direkt mit einer Stromquelle verbunden spannen diese auch einen AP auf. Die Settings in ESP-Link sind auch gesetzt (Reset GPIO0 usw.). Hardware schließe ich erstmal aus.

Wenn ich dann aber einen dieser ESP-01 auf das Board setze kann ich nicht mehr per Wlan drauf zugreifen, es wird kein AP aufgespannt. Stromversorgung über USB-Netzteil, nicht am PC.

Ich habe auch einen Pufferkondensator auf dem Board, 470uF sollten reichen. Auf der Rückseite ist eine Lötbrücke CHPD1 gesetzt. Egal ob mit oder ohne Lötbrücke, kein Unterschied.

Aktuell ist noch kein CC1101 Modul montiert, denke aber nicht, dass es daran liegt.

Habe ich irgend etwas falsch gemacht, muss ich noch irgendwo eine Lötbrücke setzen, fehlt ein Bauteil? Gibt es irgend wo eine Anleitung wie mal die ESP-01 flasht, was sonst noch eingestellt werden muss? Ich habe die normale a-cul Firmware 5500 BL geflasht. Alles nach Anleitung, hat auch funktioniert sonst würde er in FHEM nicht erkannt.




Internals:
   CFGFN     
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-STM32_MapleCUL_d7424b66-if00@38400 4444
   DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_d7424b66-if00@38400
   FD         13
   FHTID      4444
   FUUID      5f5e2576-f33f-09ae-30c2-26cfbc888308e506
   NAME       MAPLECUL1_868
   NR         23
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_00 (F-Band: 868MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-09-13 16:00:19   ccconf          freq:6656.000MHz bWidth:58KHz rAmpl:42dB sens:16dB
     2020-09-13 21:43:19   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
     2020-09-13 21:43:19   state           Initialized
     2020-09-13 16:01:16   version         V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_00 (F-Band: 868MHz)
Attributes:
   group      Gateways
   hmId       308393
   icon       cul_868
   model      CUN
   rfmode     HomeMatic
   room       TRX
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 13 September 2020, 22:42:21
ZitatWenn ich dann aber einen dieser ESP-01 auf das Board setze

Welches MAPLE-CUL Board ?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kadettilac89 am 14 September 2020, 09:02:14
Zitat von: Ranseyer am 13 September 2020, 22:42:21
Welches MAPLE-CUL Board ?

https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/V4.0

Die aktuellste Version, 4.1
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: locutus am 14 September 2020, 13:55:02
Zitat von: kadettilac89 am 13 September 2020, 21:57:48
Wenn ich dann aber einen dieser ESP-01 auf das Board setze kann ich nicht mehr per Wlan drauf zugreifen, es wird kein AP aufgespannt.
Wohlmöglich ist hier ein Hinweis auf die Ursache hinterlegt: https://forum.fhem.de/index.php/topic,112191.msg1066107.html#msg1066107
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kadettilac89 am 14 September 2020, 14:36:22
Zitat von: locutus am 14 September 2020, 13:55:02
Wohlmöglich ist hier ein Hinweis auf die Ursache hinterlegt: https://forum.fhem.de/index.php/topic,112191.msg1066107.html#msg1066107
In dem Bild ist ein ESP-01S ... ich habe die ESP-01 hier (Vorgänger ohne S). Ich schau mal ob ich was finde wozu die beiden Lötbrücken beim Vorgänger sind.

Wollte hier nur eine Bestätigung dass mein Setup, mein Vorgehen richtig ist bevor ich mich an Schaltpläne der Bauteile mache .. was natürlich die Ursache sein könnte.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 14 September 2020, 14:59:45
Du könntest ja auch einfach mal messen.

3,3V = CH_PD, Reset, Vcc
GND = GND

GPIO0 = GND oder nicht verbunden (darf keine 3,3V haben)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kadettilac89 am 14 September 2020, 15:25:30
Zitat von: Eistee am 14 September 2020, 14:59:45
Du könntest ja auch einfach mal messen.

3,3V = CH_PD, Reset, Vcc
GND = GND

GPIO0 = GND oder nicht verbunden (darf keine 3,3V haben)

Alles zu seiner Zeit. Mir gehts erstmal darum zu klären ob das generelle Vorgehen richtig ist. Oder ... geht nru mit Version xxx, oder Jumperbrücke yyy muss gesetzt sein oder Fehler im Design bekannt, verbinde mit Kabel zzz mit ....

Wenn jemand auf Version 4.1 das am Laufen hat wäre das für mich hilfreich, wäre an den Software-Versionen interessiert. Waren auf der Platine Aktionen nötig? Habe den Maple, Kondensator und ESP verbunden. Sonst nichts. Die Lötbrücke aktuell offen ....

gibt es von der Platine einen Schaltplan damit ich die Platine mal durchmessen kann?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 14 September 2020, 15:34:33
Zitat von: kadettilac89 am 14 September 2020, 15:25:30gibt es von der Platine einen Schaltplan damit ich die Platine mal durchmessen kann?
Hier: https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/V4.0
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kadettilac89 am 14 September 2020, 15:54:58
Zitat von: Eistee am 14 September 2020, 15:34:33
Hier: https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/V4.0

ich meinte als PDF oder JPG. hab kein eagle installiert ...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: subseven am 14 September 2020, 19:44:34
Online hat Ranseyer sein Pläne hier veröffentlicht.
https://cadlab.io/project/1060 (https://cadlab.io/project/1060)
Mit dem Tool lassen sich alle Leiterbahnen/Routings nachvollziehen.

Mein Tip waere aber auch messen ob an GND=GND und 3.3v=3.3V anliegen.
Als naechstes würde ich sicherstellen, dass die GPIO den Korrekten Zustand haben, da der ESP sonst im Flashmode ist und nicht den Programmcode ausführt.

Kleines Zitat aus einen Tutorial für den ESP01:
ZitatThe bootloader mode can be launched with a specific configuration during the card reset/power-on:

CH_PD has to be HIGH
GPIO0 has to be LOW during boot (can be HIGH once in bootloader mode)
You can provoque a reset of the card by a rising edge on the RESET pin.

High entsprechen 3.3V. Das ist im Prinzip das, was Eistee bereits sagte, nur anders ausgedrückt.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kadettilac89 am 14 September 2020, 20:50:14
ich habe jetzt mal direkt gesteckt. Sobald gpoi0 mit but und gpio2 mit reset verbunden ist geht kein Wlan. Nur  mit Stromversorgung VCC, GND spannt der ESP01 den AP auf.

Ich habe ESP-Link mit der aktuellsten VErsion 3.2 und die a-fw 1.26.08 mit BL_5500 geflasht. Sind diese Versionen richtig, oder gibt es hier eine Abhängigkeit die ich falsch habe? Muss irgend ein Button gedrückt werden ...

Ich weiß, dass der ESP in Bootmodus geht wenn GPIO0 auf high geht. Ich möchte nur wissen, ob jemand mit der neusten Platine nutzt, oder irgend etwas bekannt ist. Version der Software ... bevor ich rumzumessen beginne. Da ich eine Platine und bereitgestellte Software nutze gehe ich davon aus, dass die Verkabelung passt. Darum möchte ich erstmal bei den Parametern ansetzen die ich selber beeinflussen kann. Ich habe weder die a-fw selber gebaut noch die Platine modifiziert.

Flashe vielleicht später mal die alte ESP-Link Version drauf ..
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 15 September 2020, 07:57:50
Wenn du einen Fehler an der Software ausschließen möchtest dann Betreibe den ESP doch mal einzeln und den Maple mini auch. Dachte eigentlich du hast vorhin geschrieben das das du das bereits getan hast und es nur zu einem Problem kommt wenn du alles miteinander verbindest??? Du kannst nie davon ausgehen das eine Leiterplatte fehlerfrei ist. Es gilt also, wie im Wiki auch beschrieben, erstmal nachmessen um einen Fehler an der Elektronik auszuschließen. Wenn dein ESP einzeln funktioniert und auf der Leiterplatte nicht dann sind da die Pins anders beschaltet. Das kann auch eine Lötbrücke oder eine schlechte Lötstelle sein. Oder halt eine defekte Leiterplatte. Wo ist das Problem da mal kurz nachzumessen? Lieber stundenlang an der Software fummeln?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: kadettilac89 am 15 September 2020, 10:32:26
ich vermute, dass ich eine Abhängigkeit oder irgend einen Schritt nicht mache.

Aktuell:
Maple Mini mit firmware 1.26.08 geflasht und per USB eingebunden wird in FHEM erkannt. Siehe List. Denke da hab ich nichts falsch gemacht.
- Ich habe aktuell keinen CC1101 dran. Der Maple wird aber in Fhem als initialized angezeigt. Get config liefert auch Werte zurück.

ESP-01 mit ESP-Link version 3.0.14 (aktuelle Version) ... NICHT die alpha da diese Fehler hat ... https://github.com/jeelabs/esp-link/releases
- GND - GND, VCC and VCC+CH_EN -- AP wird aufgespannt
- Configuration in ESP-Link nach den Vorgaben in Wiki ... https://wiki.fhem.de/wiki/MapleCUX-Platinen .... Reset GPIO0 usw ...

Nun ohne Platine, ohne Breadboard ... direkt auf die Pin des Maple gesteckt
- Maple mini    3v -- ESP-01 VCC
- Maple mini   3v -- ESP-01 CH_EN
- Maple mini   GND -- ESP-01 GND
--> ESP-01 mit ESP-Link funktioniert, spannt AP auf, oder wählt sich in Wlan ein ... wie erwartet

ABER:
Sobald ich jetzt die 2 fehlenden Verbindungen stecke und an Strom anschließe
- Maple mini     BUT32 -- ESP-01 GPIO0
- Maple mini     RESET -- ESP-01 GPIO2
--> ESP-01 spannt kein AP mehr auf.

Direkt auf dem Maple gesteckt um Platine, Lötbrücken auszuschließen. Nach Schaltplan ist das stecken identisch zu dem was die Platine macht bzw. verbindet. Kondensator mit drauf ändert nichts ... 3 ESP-01, 3 Maple mini getestet. Zwar selbe Marge aber eher unwahrscheinlich ....

Stromversorgung sowohl per Powerbank als auch Netzteil.

Bei diesem Setup sollte doch auch der Maple über Wlan erreichbar sein, und einen AP aufspannen. Oder ist da irgendwo ein Verständnisfehler? Oder darf CH_EN nicht angeschlossen sein, irgend einen Sinn muss die Lötbrücke CHPD1 auf der Rückseite haben, damit ist per Default EN_CH spannungsfrei.

Zur Frage bezüglich GPIO0 --- Ausgang BUT32 vom Maple Mini ist low (keine Spannung).
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 15 Februar 2022, 16:11:05
Hallo zusammen,

Ich habe 3 maplecun seit 2017 im Einsatz und erinnere mich noch, dass es ein riesen Akt war den Bootloader zu tauschen.

Seit 2 Tagen versuche ich einen vierten in Betrieb zu nehmen und es will einfach nicht. Alle Hinweise die ich bisher gefunden habe, habe ich durchprobiert. But gedrückt halten, reset lang, kurz... But während dem schnellen blinken drücken... Aber dieses Mal klappt es einfach nicht.
Hat inzwischen jemand eine idiotensichere Vorgehensweise gefunden?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 15 Februar 2022, 17:52:30
Schnell mal aus der Hüfte geschossen (Beispiel anhand des BluePill-Boards): https://www.youtube.com/watch?v=Myon8H111PQ (https://www.youtube.com/watch?v=Myon8H111PQ)
Maple- nicht BluePill-Binaries nehmen. (Die "richtige" Version der Binaries => die von Ralf9 empfohlenen nehmen!)
Mittels Arduino und Blink-Sketch verifizieren!

Benutze selbst aber eher die STLink-Variante.

Allerdings ohne Gewähr und mit dem Verweis auf diesen Thread hier (Lesen!)  :D

Jürgen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Februar 2022, 18:00:15
Zitat von: giulup am 15 Februar 2022, 16:11:05
Hat inzwischen jemand eine idiotensichere Vorgehensweise gefunden?

Ich flashe schon länger nicht mehr. Aber ich habe immer But gedrückt und dann erst das USB Kabel mit der Spannungsversorgung eingesteckt und dann den Button losgelassen...

Das war für mich der einfachste Weg.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 15 Februar 2022, 18:42:32
Zitat von: Ranseyer am 15 Februar 2022, 18:00:15
Ich flashe schon länger nicht mehr. Aber ich habe immer But gedrückt und dann erst das USB Kabel mit der Spannungsversorgung eingesteckt und dann den Button losgelassen...

Das war für mich der einfachste Weg.

Das habe ich auch schon mehrfach probiert. Dann bleibt mir nur mich dem Wahnsinn zu stellen.

Gab es die Probleme nur beim Flash loader demonstrator oder auch mit stm32flash? Den habe ich bisher nicht ausprobiert, da ich nie dahinterkam wie man den benutzt
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 15 Februar 2022, 18:55:50
Hast du das Flashen so gemacht wie hier beschrieben?
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 15 Februar 2022, 19:04:41
Zitat von: Eistee am 15 Februar 2022, 18:55:50
Hast du das Flashen so gemacht wie hier beschrieben?
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen
Jap. Das Wiki hab ich schon durch. Nur stm32flash bisher nicht
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ralf9 am 15 Februar 2022, 19:06:04
Hast Du getestet ob der Bootloader 2.0 schon drauf ist? Es kommt ab und zu auch vor, daß bei den MapleMini, die in der letzten Zeit gekauft wurden, der Bootloader 2.0 schon drauf ist.

Es gibt auch die Möglichkeit den Bootloader 2.0 über USB zu flashen
https://forum.fhem.de/index.php/topic,106278.msg1073244.html#msg1073244

Gruß Ralf
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 15 Februar 2022, 19:37:46
Zitat von: Ralf9 am 15 Februar 2022, 19:06:04
Hast Du getestet ob der Bootloader 2.0 schon drauf ist? Es kommt ab und zu auch vor, daß bei den MapleMini, die in der letzten Zeit gekauft wurden, der Bootloader 2.0 schon drauf ist.

Es gibt auch die Möglichkeit den Bootloader 2.0 über USB zu flashen
https://forum.fhem.de/index.php/topic,106278.msg1073244.html#msg1073244

Gruß Ralf

Hmm das hab ich nicht getestet. Wie gehe ich dafür vor? Die minis die ich hier liegen sind glaube ich noch aus 2018.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 15 Februar 2022, 19:39:43
ZitatDas habe ich auch schon mehrfach probiert. Dann bleibt mir nur mich dem Wahnsinn zu stellen.
Gab es die Probleme nur beim Flash loader demonstrator oder auch mit stm32flash?
Den habe ich bisher nicht ausprobiert, da ich nie dahinterkam wie man den benutzt

Müsste man dann nicht einen Schritt zurückgehen und dann nochmal konzentriert und neu mit nur einer Vorgehensweise  anfangen?
Es ist wirklich kein Wahnsinn und viele andere haben es auch geschaftt, sogar mit weniger verfügbaren Informationen als heutzutage!
Habe das Gefühl, Du machst Dir das Leben selbst schwer....

Welche Basis-Platine des MapleCULs nutzt Du?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 15 Februar 2022, 19:55:10
Zitat von: juergs am 15 Februar 2022, 19:39:43
Müsste man dann nicht einen Schritt zurückgehen und dann nochmal konzentriert und neu mit nur einer Vorgehensweise  anfangen?
Es ist wirklich kein Wahnsinn und viele andere haben es auch geschaftt, sogar mit weniger verfügbaren Informationen als heutzutage!
Habe das Gefühl, Du machst Dir das Leben selbst schwer....

Welche Basis-Platine des MapleCULs nutzt Du?

Ich selbst habe ja auch schon ein paar hinbekommen. Das ist aber schon eine ganze Weile her und ich bekomme es nicht mehr hin. Damals waren es die large Platinen. Jetzt habe ich mir eine small vorgenommen die seit 2018 auf mich wartet.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Maui am 15 Februar 2022, 20:00:30
Ansonsten schau dir mal den Abschnitt Bootloader flashen ohne TTL an. Hatte den damals mal geschrieben und das war eigentlich "idiotensicher"
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 15 Februar 2022, 20:06:58
Hast du den Maple schon verlötet, sind schon CC1011 oder anderes verbaut ?

(Ich erinnere mich düster, dass ich da auch schon mal Probleme hatte beim Flashen. Im speziellen wenn sogar noch das LAN Modul verbaut war. Das zieht mehr Strom und wird ggf. das Flashen "nicht erleichtern". )

Ich schliesse zum Flashen normalerweise so an:

- FTDI-oder-so <=> Debug-Port-am_MAPLECUL: GND, TX+RX gekreuzt  (Keine Versorgungs-Spannung)

- USB Buchse des Maple (oder Alternatives) zur Spannungsversorgung => ergibt 3,3V an VCC beim MAPLE



Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 15 Februar 2022, 20:40:29
Zitat von: Ranseyer am 15 Februar 2022, 20:06:58
Hast du den Maple schon verlötet, sind schon CC1011 oder anderes verbaut ?

(Ich erinnere mich düster, dass ich da auch schon mal Probleme hatte beim Flashen. Im speziellen wenn sogar noch das LAN Modul verbaut war. Das zieht mehr Strom und wird ggf. das Flashen "nicht erleichtern". )

Ich schliesse zum Flashen normalerweise so an:

- FTDI-oder-so <=> Debug-Port-am_MAPLECUL: GND, TX+RX gekreuzt  (Keine Versorgungs-Spannung)

- USB Buchse des Maple (oder Alternatives) zur Spannungsversorgung => ergibt 3,3V an VCC beim MAPLE

Ich habe einen verlötet und einen frischen durchprobiert. Die wollen beide bisher nicht. Ich bin mir natürlich sicher, dass das Problem vor dem Bildschirm sitzt. Immerhin hat es mit dem identischen Setup schon funktioniert. Den Hinweis mit der Versorgungsspannung habe ich auf einer der Seiten in diesem Thread gelesen und es schon ein 30Watt Netzteil versucht.

Irgendwann wird es wohl klappen ohne dass ich erkennen kann warum
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ralf9 am 16 Februar 2022, 11:27:49
ZitatHmm das hab ich nicht getestet. Wie gehe ich dafür vor? Die minis die ich hier liegen sind glaube ich noch aus 2018.
Bei so einem alten Maple brauchst Du nicht mehr prüfen ob bereits der Bootloader 2.0 bereits drauf ist.

Den Bootloader flashen ohne TTL-Adapter finde ich am einfachsten. Damit kann der Bootloader 2.0 auch recht einfach schon vor dem verlöten geflasht werden.

Nach der Beschreibung im Wiki muß der updater sketch mit der Arduino IDE compiliert und dann auf den Maple hochgeladen werden.

Bei meiner Beschreibung liegt der updater sketch bereits als bin File vor und muss nur noch mit "dfu-util" geflasht werden.

Der Rest ist bei beiden Beschreibungen gleich
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 16 Februar 2022, 14:31:33
Zitat von: Ralf9 am 16 Februar 2022, 11:27:49
Bei so einem alten Maple brauchst Du nicht mehr prüfen ob bereits der Bootloader 2.0 bereits drauf ist.

Den Bootloader flashen ohne TTL-Adapter finde ich am einfachsten. Damit kann der Bootloader 2.0 auch recht einfach schon vor dem verlöten geflasht werden.

Nach der Beschreibung im Wiki muß der updater sketch mit der Arduino IDE compiliert und dann auf den Maple hochgeladen werden.

Bei meiner Beschreibung liegt der updater sketch bereits als bin File vor und muss nur noch mit "dfu-util" geflasht werden.

Der Rest ist bei beiden Beschreibungen gleich

Da muss ich dann also trotzdem durch die undurchschaubare Boot-reset-schleife.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ralf9 am 16 Februar 2022, 14:41:12
Nein, wenn Du nach dem Drücken der Reset Taste innerhalb ca 1 Sek den Flash Befehl ausführst, ist diese undurchschaubare Boot-reset-schleife nicht notwendig
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 16 Februar 2022, 15:22:18
Zitat von: Ralf9 am 16 Februar 2022, 14:41:12
Nein, wenn Du nach dem Drücken der Reset Taste innerhalb ca 1 Sek den Flash Befehl ausführst, ist diese undurchschaubare Boot-reset-schleife nicht notwendig
Also ist auch das Timing im Flash-Tool wichtig? Liegt das bei 1 sec oder ist es noch zeitkritischer?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Eistee am 16 Februar 2022, 15:44:33
DFU über USB geht nur wenn ein Bootloader installiert ist der auch DFU kann. Alle Maple mini Module die ich bisher in der Hand hatte hatten im Auslieferungszustand keinen DFU fähigen Bootloader drauf.
Für mich war es immer am einfachsten mit dem FTDI Adapter.

Was bitte sind für euch "undurchschaubare Boot-reset-schleifen" ????

Flashmodus bei den STM32 Chips heißt immer die boot1 auf GND legen und beim starten muss But32 gedrückt sein um ihn in den Flashmodus zu bringen. Ob man Ihn nun mit dem Reset Taster neu startet oder den But32 gedrückt hällt und dann die Spannungsversorgung einschaltet ist egal. Ich vermute mal das hier irgendwas anders gemacht wird als es im Wiki erklärt wird.

Meine Vermutungen:
- Die Brücke von boot1 auf GND fehlt.
- Es wurde irgendwas in den USB Anschluss vom Maple mini gesteckt während versucht wird Ihn über rx1 und tx1 zu flashen.
- Falscher COM Port oder Einstellungen im STM32 Flash Loader Demonstrator gewählt. Hier unbedingt die Bilder im Wiki beachten und den richtigen COM Port im Gerätemanager ermitteln.

Zum DFU flashen über USB gibt es ein Script welches das DFU command in einer Schleife ausführt. Der Maple mini ist beim booten nur einen kurzen Moment im DFU Flashmodus. Dazu muss KEIN Taster gedrückt werden. Ich habe dazu immer das Script gestartet und dann den Maple mini am USB angeschlossen. Das funktioniert bei mir sehr zuverlässig. Ich muss aber dazu sagen das ich das DFU flashen immer mit dem raspberry PI gemacht habe und das bootloader flashen unter Windows mit dem STM32 Flash Loader Demonstrator

Auf den letzten Maple CUN die ich gebaut habe habe ich den MSC bootloader geflasht da es hier noch einfacher ist eine neue firmware aufzuspielen. Es braucht dann kein DFU mehr sondern man kopiert einfach eine Datei aufs Laufwerk.

Gruß Alina
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: giulup am 16 Februar 2022, 17:27:49
Ich glaube da ist etwas durcheinander geraten. Ich hänge immernoch beim bootloader, wobei ich es bei einem maple (natürlich noch nicht verlötet) auf einmal heute hinbekommen habe. Keine Ahnung wieso es auf einmal ging. Reproduzierbar ist es nicht. Nicht mal auf dem gleichen
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ralf9 am 16 Februar 2022, 19:54:39
Bis jetzt hatten bei mir alle Maple Mini im Auslieferungszustand den Maple DFU Bootloader Orginal oder 2.0 drauf.

Das lässt sich ja ganz einfach testen, wenn damit
sudo ./dfu-util -v -d 1eaf:0003 -a 1 -D updater_stm32f1.bin -R
das flashen funktioniert, dann ist bereits ein DFU Bootloader drauf.

Ich habs auch aufgegeben mit der But und Reset Tastenfolge in den Flash Modus zu kommen.
Mit "dmesg -w" müsste man es eigentlich sehen können, wenn er im Flash Modus ist

Mit Reset und dann innerhalb ca 1 Sek zu flashen funktionierts bei mir zuverlässig

Gruß Ralf
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dio_2001 am 21 Juli 2022, 17:38:07
Hallo Zusammen,

Ich brauche dringend Hilfe und Hoffe dass ich hier richtig bin.
ich habe seit einigen Jahren ein Maplecun in Betrieb (Ich habe das Teil fertig von Alina Mosig gekauft). Das Teil hängt bei mir im LAN und lief bis vor ca. einem Monat einwandfrei.
Dann war das Teil im Netz plötzlich nicht mehr zu sehen (und in fhem "disconnected"). Wenn ich die Stromversorgung ab- und wieder angeschlossen habe war alles wieder in Ordnung.
Diese Problem hat sich gehäuft bis es jetzt gar nicht mehr geht.

wenn ich Spannung anlege leuchten die Dioden, das WLAN Netz wird ab und an aufgespannt "MAPLECUN".
Beim letzten Test habe ich festgestellt, dass ein Bauteil auf dem MAPLE Board (ich vermute der Spannungsregler) sehr heiss wird.

Ich weiss leider nicht mehr weiter. Hat Irgendjemand eine Idee?
Danke, Dieter
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 21 Juli 2022, 17:51:55
Hallo Dieter.

Ich habe das gleiche Problem bei meinem nachgebauten cul.
Ich bin dann auf das lanmodul umgestiegen.  Dann hatte ich keine Probleme mehr mit dem spannungswandler. Ist das usb Teil für die Stromversorgung? Ich habe ein holbuchse verwendet.
Ich habe auch noch ein WLAN cul der läuft. Ich musste da nur ein Leiterin trennen sonnst ist er immer nicht gestartet.

Grüße André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 21 Juli 2022, 19:19:00
Zitat von: dio_2001 am 21 Juli 2022, 17:38:07
wenn ich Spannung anlege leuchten die Dioden, das WLAN Netz wird ab und an aufgespannt "MAPLECUN".


Liegen denn superstabil hier 3,3V an ?
https://iotspace.dev/esp-01-pinout-und-technische-daten/

Welcher Spannungsregler wird heiss ? Der auf dem Maple ?

Ein fetter Elko könnte Abhilfe schaffen. Wenn aktuell z.B. wegen gealterten Bauteilen die 3,3V zusammenbrechen, dann startet das WLAN neu, das braucht dann mehr Strom solange bis es stabil läuft. (Bei dir also nie)

Die Platine dürfte von hier sein: https://github.com/ranseyer/CUN-STM32
Somit sollte es auch Platz für eine ordentlichen Kondesator geben. 100-1000uF irgend sowas mit mindestens 6V Spannungsfestigkeit.

Zusätzlich noch 10-50pF Keramikkondensator z.B. am Eingang des ESP01 Moduls falls noch immer Probleme...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dio_2001 am 21 Juli 2022, 20:50:26
Das Bauteil ist der ASS1117 auf dem MAPLE nach meinen Recherchen ein Spannungsregler.  Den Kondensator babe ich ausgetauscht war ein 220mF und durch gleichen ersetzt. Keine Verbesserung - der alte Elko ist auch noch in Ordnung, konnte ihn messen.
Die Spannungen kann ich morgen versuchen zu messen.  (Just zur Info, meine Elektronik-Kenntnisse enden dort wo die IC's angefangen haben).

Ich habe das CUN heute noch en meinen PC angeschlossen. Dieser versucht ständig das Device einzurichten und bricht wieder ab.
Ausserdem habe ich noch festgestellt, dass die LAN LED's glimmen wenn ich ein Netzkabel anschliesse.

Ich messe morgen die Spannungen, dann sehen wir weiter.
Das blöde ist halt, dass ich das Teil im Netz brauche (Ich fahre MAX (Thermometer) und Homematic (Heizkreisventile) für die Fussbodenheizung und das zieht sich  über 3 Stockwerke).

Danke schon einmal,
Dieter

Ich habe noch ein Bild angehängt und das Teil, dass heiss wird eingekreist.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 21 Juli 2022, 21:10:17
Sind die Sachen alle verlötet, oder kannst du unnötiges (Arduino, ESP01 Modul) enfernen ?

Wenn der MAPLE selbst auch ständig neu startet gibt es ja ein Problem mit globaler Auswirkung.

Woher kommt denn der Saft ? Falls von einem USB Netzteil mit Intelligenz solltest du unbedingt eine aktuelle Firmware haben. (Die letzte haz auch schon wieder eine Menge Zeit auf dem Buckel, meldet sich aber korrekt als Gerät mit mehr als 50mA Verbrauch)

Kannst du die 3,3V messen ?

Ansonsten kannst du ja auch mal Alina anschreiben.
(Der Vorschlag mit der Hohlbuchse kam ja schon mal)

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dio_2001 am 22 Juli 2022, 13:33:30
Ich benutze seit Jahren dasselbe Netzteil - welches weiss ich nicht mehr genau und komme ich auch nur sehr schlecht dran.

Folgendes habe ich getan:

Spannungsmessung: da wo 3,3 V anliegen sollte habe ich im ersten Schritt 2,2V gemessen. (Alle Module entfernt)
Dabei habe ich am festgestellt, dass die LEDs am LAN Modul schwach glimmen. 

Ich habe dann das LAN Modul ausgelötet. (War gar nicht so einfach).
Danach lag die Spannung bei 2,6 V (Egal ob mit oder ohne Module) und die LEDs an den Modulen leuchten wieder.

Dann das MapleCUN am Raspi angeschlossen - und siehe da - ich sehe das CUL wieder.
(usb-STM32_MapleCUL_c675e93f-if00 bis if04)
Ich konnte es auch noch in FHEM definieren. Dann ist die Spannung nach kurzer Zeit wieder zusammengebrochen.

Im Moment weiss ich mir keine Rat mehr.

@Andre, das WLAN (Esp) auf dem Board meldet sich seither nicht mehr.

Frage, wie erreiche ich Alina denn? Habe sie hier nicht gefunden und ihren Shop macht sie nicht mehr.


Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: Ranseyer am 22 Juli 2022, 13:47:21
A) 2,6 V statt 3,3V ist viel zu wenig !


B) Das Problem bei der Paralellschaltung ist, dass du einen Kurzschluss fast nur durch auftrennen der einzelnen Teile finden kannst...
Mit Pech genau an der letzten Stelle:
https://de.universaldenker.org/formeln/1242
PS: Wenn dein Finger hitzeempfindlich ist kannst du evtl auch damit den Kurzschluss finden falls vorhanden.

C) Such doch mal die Userin "Eistee" hier im Forum oder schau auf deine Rechnung.



PPS: Als allererstes zum Punkt A): Ein neues Netzteil testen ! (Das Alte kann dazu ja erst mal versteckt bleiben)

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 22 Juli 2022, 13:54:54
Hallo

Ich kann am we mal den cun heraussuchen und nachschauen welche Leiterbahnen ich getrennt habe. Das Problem mit dem spannungswandler hatte ich auch.

Grüße André
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: rieders am 22 Juli 2022, 17:05:11
Hier 2 Bilder
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dio_2001 am 23 Juli 2022, 14:12:18
Hallo Zusammen,

danke erst einmal für die ganzen Hinweise.

Ich habe als nächsten Schritt beschlossen, das Maple Board und das LAN Modul neu zu bestellen. Dann werde ich mit Hilfe von einem Bekannten versuchen das  Maple auszulöten und zu ersetzen. Dann wieder messen und - wenn notwendig - weitersuchen.

Frage: welches Binary muss ich für das grosse Board downloaden? Und welche SW kann ich für das Flashen unter Windows (oder zur Not auch MAC) verwenden? Irgendwie finde ich mich in den ganzen Anleitungen nicht wirklich zurecht.

Inzwischen habe ich noch 2 USB CULs ausgegraben, damit zumindest meine  Heizungssteuerung (ich heize nicht, sondern nutze meine Wärmepumpe zum Kühlen) und die Gartenpumpe wieder funktioniert.

Ich melde mich sobald die Teile eingelötet sind.

Hoffentlich klappt das alles.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: dio_2001 am 28 Juli 2022, 09:05:35
Hallo Zusammen,

das MAPLECUN funktioniert im Moment wieder.
Nachdem ich gar nicht mehr weitergekommen bin, hatte ich das Glück, das mir ein Bekannter Hilfe angeboten hat.
Hier ein kurzes Recap:
Wir haben alle (Steck-)Module entfernt und er hat ein neues W5500 eingebaut (sicherheitshalber auf Sockel). Dann hat er festgestellt, dass auf dem MAPLEBoard eine Diode defekt war (die neben dem Spannungsregler) und diese ausgetauscht.
Leider war der Effekt begrenzt. Die Spannungen waren weiterhin alle zu niedrig e.g.: 2,2V an den Transceivern).
Gleichzeitig hat er mir gesagt, dass die meisten Lötstellen nicht von guter Qualität sind (Wie gesagt, ich habe es nicht gebaut)

Er hat das Board mit zu sich in die Firma mitgenommen und überprüft. Kontaktierungsprobleme gefunden und behoben
(Details habe ich leider noch keine). An allen Stellen messen wir jetzt wieder die richtigen Spannungen.
Mir ist noch nicht klar warum schlechte Kontaktstellen dies Problem auslösen konnte.

Das Board ist jetzt ohne Zusatzmodule in Betrieb und ich werde es nicht anfassen bevor ich (mindestens eins, da ich ein Backup haben möchte) ein neues gebaut habe.

Gibt es eine Empfehlung welche Board Version ich nutzen sollte?

Auf jeden Fall erst einmal vielen Dank für eure Unterstützung.

Dieter



Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: ThomasHome am 30 November 2022, 20:53:59
Hallo zusammen,
ich habe ein Bord, bei welchem der USB Stecker leider abgebrochen ist. Da man diesen, wenn der Maple Mini verlötet ist nicht mehr einfach auflöten kann, versorge ich das Board mit einem an Vin angelötete MicroUSB Stecker. Das ging auch. Jetzt kam ich auf die Schnapsidee von V 1.24 auf 1.26 ein Firmwareupgrade durchzuführen. Also habe ich stumpf mit stm32flash die aktuelle MapleCUNx4W550_BL.bin drauf geflasht (stm32flash -w MapleCUNx4_W5500_BL.bin -v /dev/ttyUSB0). Jetzt tut der MapleCUN leider nicht mehr. Firmwareupgrade per MSC Bootloader geht mangels MiniUSB (ist ja abgebrochen) nicht.

Hat jemand eine Idee? Per stm32flash kann ich ja über die Debug Schnittstelle flashen.

Beste Grüße
Thomas
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 30 November 2022, 21:35:43
Flashen  kannst Du ,,einfach" über einen Stlink v2 Adapter.
Dieser lässt sich leicht aus einem Weiteren STM32 (BluePill etc). herstellen.
Da solltest Du fündig werden:
https://forum.fhem.de/index.php/topic,109440.msg1034277.html#msg1034277 (https://forum.fhem.de/index.php/topic,109440.msg1034277.html#msg1034277)
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: ThomasHome am 01 Dezember 2022, 08:53:06
Ah super. Danke. So einen hab ich noch bei den Eltern rum liegen. Probiere ich Weihnachten rum aus und melde mich.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: ThomasHome am 01 Dezember 2022, 15:34:59
@juergs:
Jetzt doch noch eine doofe Frage: ist das per STLink dann anders? Per FTDI habe ich ja die "MapleCUNx4_W5500_BL.bin" raufgeflasht. War laut stm32flash auch erfolgreich. Danach ging nur nix mehr  :-\
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 01 Dezember 2022, 15:47:58
Hallo Thomas,
hatte mich auf die kaputte USB Buchse eingeschossen.
Zitat...Firmwareupgrade per MSC Bootloader geht mangels MiniUSB (ist ja abgebrochen) nicht
Mit dem STLink-Adapter kannst Du den Maple und Bootloader ohne USB neu programmieren.
Da es aber mit dem FTDI zu flashen ging, bist Du sicher, dass die Binary-Adresslage passte? Bootloader überschrieben?
Blinkt der Bootloader?
War vorher auch die CUN-FW "a-culfw shared by Bjoern Hempel" drauf?
Welches Board?

Zitathttps://forum.fhem.de/index.php/topic,60458.msg645248.html#msg645248

Zeig mal ein Screenshot vom FL-Demostrator (https://wiki.fhem.de/wiki/MapleCUN).

Ggf. Bootloader neu drauf und nochmal die Binary.
Wenn das nicht funktioniert: Probiere ein Arduino Blink-Sketch zum Blinken der Led aus.
Natürlich mit anderen Blinkfolgen als die des Bootloaders ;-) um zu prüfen ob der Maple noch funktioniert....

Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 05 Februar 2023, 15:52:05
Hi Ihr,

ich hab jetzt lange auf dem MapleCUL eine Zigbee-Platine CC2530 betrieben. Aber laut zigbee2mqtt ist das ja nur noch "zweite Wahl" und daher hab ich mir jetzt separat einen "Slaesh's CC2652RB stick" (USB-Stick) mit eben diesem Chip an den Rechner gesteckt. Also leider als separates USB-Gerät (gibt es ja wohl nicht als MapleCUL-Addon wie beim CC2530, oder?).
Da ich getriggert durch die aktuellen Strompreise etwas im Stromspar-Wahn bin, überlege ich, ob ich jetzt die CC2530-Platine vom MapleCUL sogar abziehen sollte. Der Stromverbrauch davon ist sicherlich nur minimal (oder?), aber wenn ich sie (momentan) sowieso nicht benutze, sehe ich auch keinen Mehrwert, sie gesteckt zu lassen?
Oder wie seht ihr das? Spart man da messbar Strom bzw. seht ihr andere Vorteile, wenn ich die Platine drauf lasse?
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 05 Februar 2023, 17:50:08
Hallo vbs,
seltsam, habe mir jetzt noch nicht dem absoluten Sparwahn hingegeben bzw. hinreißen lassen,
allerdings habe ich gerade die selbe Konstellation mit Austausch CC2530 gegen den CC2652 und Integration in FHEM in Arbeit.  :)
Kämpfe gerade mit den Stromsparmechanismen in Ubuntu, weil Zigbee2MQTT und Docker-Container-Instanzen etc.. nicht sofort verfügbar sind ...

Allerdings sehe ich den "zählbaren" Verbrauch eines USB Gerätes im Empfangsmodus eigentlich m.M.n  als vernachlässigbar an.
Die Stromspitzen sollen ja nur im Sendebetrieb entstehen und zwar nur über die kurze Zeit des Telegramms... 

Aber ich kann gerne mal mein Thin-Client (https://forum.fhem.de/index.php/topic,126838.msg1248210.html#msg1248210) mit Ubuntu-Server mit und ohne Zigbee messen.
Meine aber, dass man den Unterschied nicht sehen wird, lasse mich aber gerne überraschen ...  ;)
Gruß,
Jürgen

PS: Gewichtiger wäre wohl der Verbrauch der Zigbee-Devices im EIN-Zustand, wie z.B. der Steckdosenschalter etc.  ;D

PS2: WLAN-Stick + Maple4xCUL + MapleMiniCUL + Zigbee CC2530 abgezogen ~ < 1W (4 USB-Geräte abgezogen)

ZitatSpart man da messbar Strom bzw. seht ihr andere Vorteile, wenn ich die Platine drauf lasse?
Sollte jetzt selbstredend sein ... ~3.50€/Jahr für alle 4 USB-Devices.
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 05 Februar 2023, 22:59:24
Hi Jürgen,

wow, danke dir für die Mühe! Bin nicht sicher, ob ich es richtig verstanden hab:
PS2: WLAN-Stick + Maple4xCUL + MapleMiniCUL + Zigbee CC2530 abgezogen ~ < 1W (4 USB-Geräte abgezogen)
Also der CC2530 liegt allein bei einem knappen Watt? So lese ich auch deine Diagramme. Also ja, ist natürlich wirklich nicht viel, aber dann ja tatsächlich messbar. Ich hätte sogar noch deutlich weniger erwartet.
Also klingt doof, aber dann werde ich es bei mir doch auch abziehen, wenn es wirklich keinen Nutzen bringt ;D

Es läppert sich ja alles irgendwie... Meine Wifi-Tasmotas liegen so bei 0,7 W und zumindest mein Messgerät zeigt bei den Zigbee-Smartplugs 0,0 W an (Zigbee sollte ja auch stromsparender als Wifi sein). Also ein Wechsel auf eine 10€-Zigbee-Plug würde sich schon nach 4-5 Jahren amortisiert haben  8) Ja ja, ich weiß... aber optimieren macht ja auch Spaß...
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 05 Februar 2023, 23:01:34
ZitatAlso der CC2530 liegt allein bei einem knappen Watt?
Nein, kleine Korrektur: alle 4 (mit WLAN) . Der Zigbee-Stick dürfte also deutlich weniger als 250mW brauchen..
Titel: Antw:Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 12 Februar 2023, 12:11:32
Zitat von: juergs am 05 Februar 2023, 17:50:08
PS: Gewichtiger wäre wohl der Verbrauch der Zigbee-Devices im EIN-Zustand, wie z.B. der Steckdosenschalter etc.  ;D
Da hast du übrigens voll recht: Obwohl die SmartPlugs ausgeschaltet bei 0 W liegen, ziehen sie eingeschaltet ca. 0,5 W  :o Für mich jetzt als Laie irgendwie überraschend. Hätte gedacht, da wird beim Schalten ein Schalter umgelegt und gut ist. Ist offenbar ein Releais, dass dauerhaft unter Spannung stehen muss oder so...
Naja, 0,5 W ist jetzt nicht so viel, aber wenn man die Dose einsetzt, um im ausgeschaltet Zustand zB 2 W zu sparen und dafür eingeschaltet wieder 0,5 W hergibt, dann muss man sich das schon gut überlegen  ::)
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: my-engel am 04 Juni 2023, 20:30:08
Hallo,

der MapleCUN stellt ja über das Netzwerk den UART0 und UART1 bereit.
Dies funktioniert soweit. Die Frage ist, ob man das Datenformat
von 8-N-1 abändern kann???

Danke und VG
Uwe
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 04 Juni 2023, 21:36:50
Das Datenformat 8-N-1 ist fest vorgegeben. Wenn du das ändern möchtest, musst du das direkt im Quellcode ändern und neu compilieren. Ist zu finden in der Datei culfw/STM32/hal_usart.c

void MX_USART2_UART_Init(void)
{

  huart2.Instance = USART2;
  huart2.Init.BaudRate = 115200;
  huart2.Init.WordLength = UART_WORDLENGTH_8B;
  huart2.Init.StopBits = UART_STOPBITS_1;
  huart2.Init.Parity = UART_PARITY_NONE;
  huart2.Init.Mode = UART_MODE_TX_RX;
  huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart2.Init.OverSampling = UART_OVERSAMPLING_16;
  if (HAL_UART_Init(&huart2) != HAL_OK)
  {
    Error_Handler();
  }
  HAL_UART_Receive_IT(&huart2, &inbyte2, 1);
}
/* USART3 init function */

void MX_USART3_UART_Init(void)
{

  huart3.Instance = USART3;
  huart3.Init.BaudRate = 115200;
  huart3.Init.WordLength = UART_WORDLENGTH_8B;
  huart3.Init.StopBits = UART_STOPBITS_1;
  huart3.Init.Parity = UART_PARITY_NONE;
  huart3.Init.Mode = UART_MODE_TX_RX;
  huart3.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart3.Init.OverSampling = UART_OVERSAMPLING_16;
  if (HAL_UART_Init(&huart3) != HAL_OK)
  {
    Error_Handler();
  }
  HAL_UART_Receive_IT(&huart3, &inbyte3, 1);
}
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: my-engel am 04 Juni 2023, 21:58:21
Danke dir,

ist die USART1 die Debug Schnittstelle?

VG
Uwe
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: Telekatz am 04 Juni 2023, 23:03:58
Ja, USART1 ist die Debug Schnittstelle.
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 21 Juni 2023, 18:37:29
Ich hab seit gestern das Problem, dass FHEM keine Fernbedienungssignale mehr erkennt. Auf einmal wird wohl bei meinem Maple der 433 MHz Transceiver nicht mehr erkannt. So zumindest meine Diagnose. Ich bin da nicht mehr so im Thema drin bzgl. Debugging. Vielleicht könnte mich jemand in die richtige Richtung leiten, bitte?

Wenn ich in FHEM bei dem 433-Trans "get ccconf" ausführe, dann kommt nur "No FD". Der 868 Transceiver antwortet noch brav mit der Config.

Wenn ich FHEM runterfahre, und den Port auf der Console per Hand aufmache, sieht es so aus:
V 1.26.05 a-culfw Build: private build (unknown) MapleCUNx4_01 (F-Band: 868MHz)
? (*V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
? (**V is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z
Also soweit ich weiß, ist dann "V" der erste Transceiver und "*V" würde dann der zweite sein, oder? Also bei "*V" kommt halt auch nix. Also würde ich sagen, Transceiver wird nicht mehr erkannt?

Hat jemand ne Idee, woran sowas liegen könnte? Wenn ich am Debug-Port mitlesen würde, könnte ich sehen, welche Transceiver erkannt werden, richtig? Müsste ich aber erst aufbauen. Und würde da vielleicht auch nur bestätigt bekommen, dass der zweite Transceiver weg ist?

Ich hab noch so einen 433-Transceiver im Schrank irgendwo. Wird der kaputt sein und sollte ich den mal austauschen?

20230621_182827.jpg
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 21 Juni 2023, 19:26:00
Hm gerade viel gefummelt und ab und zu wird der Transceiver erkannt. Nach Power-Cycle besteht wohl immer eine gewisse Chance, dass er erkannt wird. Klingt wie Wackelkontakt, oder? Aber alle Lötpunkte sehen so optisch echt bombenfest aus. Keiner dabei, der mir verdächtig vorkommt.
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 21 Juni 2023, 20:02:44
Hallo vbs,

sieht wirklich nach einem Zugriffsproblem auf das 433MHz-Modul aus.
Fangen wir mal einfach an:
Wie sieht es mit dem Pendant zum C1 auf Deinem Bild aus?
Kannst Du den messen/prüfen?
Liegt wirklich im Betrieb  an den VCC/GND-Anschlüssen des Moduls Spannung an (3V3/GND)? GND Kontakt?

Ich habe noch eine ältere Version am Start:
ein "get raw *V" auf den 868-Teil ergibt bei mir:
MapleCUL868 raw => *V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)
Konfiguration als :STACKABLE_CC
"MapleCUL433 Initialized"?

Laut Bild könntest Du evtl. Diese Version haben, mit RADIO3 = CC4 mit dem 433er Modul bestückt?   
Schaltplan (https://raw.githubusercontent.com/ranseyer/CUN-STM32/master/HW-MAPLE-Large/Archiv/Charge1-ohne%20Versionsaufdruck/Schematic.png)

Die "no FD"-Meldung kommt, wenn das betroffene Modul nicht korrekt initialisiert werden kann... oder es kommen unsinnige Frequenzwerte ....

Mehr lässt sich aus Deinen Infos nicht herauslesen ... ;-(

Modulreihenfolge:
https://forum.fhem.de/index.php?topic=68811.0
Ob das mittlerweile überholt ist?

Konfetti: Mein 2000. Beitrag :-)

Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 21 Juni 2023, 21:39:31
Hey Jürgen, schonmal danke für die Antwort und Glückwunsch zum 2000. Post  :))

Zitat von: juergs am 21 Juni 2023, 20:02:44Wie sieht es mit dem Pendant zum C1 auf Deinem Bild aus?
Kannst Du den messen/prüfen?
Hm, klingt vielleicht blöd, aber sieht für mich so aus, als gäbe es da kein Pendant? Kann das sein?

Also das ist ein 3.4 Board und der 433-Transceiver sitzt wohl auf CC1. Gemäß der Schematics gibt es da keinen Kondensator wie für CC0?
https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/Archiv/V3.4/Schematic.png


Zitat von: juergs am 21 Juni 2023, 20:02:44Liegt wirklich im Betrieb  an den VCC/GND-Anschlüssen des Moduls Spannung an (3V3/GND)? GND Kontakt?
Werde ich mal prüfen. Macht es generell Sinn, mal alle Beinchen auf Verdacht neu zu löten (also einmal heiß machen)? Oder macht man sowas nicht?  O:-)

Zitat von: juergs am 21 Juni 2023, 20:02:44Laut Bild könntest Du evtl. Diese Version haben, mit RADIO3 = CC4 mit dem 433er Modul bestückt?   
Schaltplan (https://raw.githubusercontent.com/ranseyer/CUN-STM32/master/HW-MAPLE-Large/Archiv/Charge1-ohne%20Versionsaufdruck/Schematic.png)
Sorry, hätte ich dazu sagen sollen: ist eine Version 3.4

Zitat von: juergs am 21 Juni 2023, 20:02:44Modulreihenfolge:
https://forum.fhem.de/index.php?topic=68811.0
Ob das mittlerweile überholt ist?
Also das Thema kenna ich generell, aber würde ich ausschließen, da ich ja auf der Console mit "*V" auch ohne FHEM "nachweisen" kann, dass der Transceiver nicht da ist.
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 22 Juni 2023, 16:49:27
Also hab etwas gefummelt:

Nochmal alles einmal nachgelötet, aber, wie befürchtet, keine Änderung.

Ich hab mal die Versorgungsspannug an dem CC1101 gemessen und das war auch in Ordnung.

Hab dann mal den CC1101 runtergelötet und einfach gegen einen baugleichen ausgetauscht und das scheint es gebracht zu haben. Hab jetzt 20 Mal gepowercycelt und jedes Mal wurde der CC erkannt. Bleibt ein etwas ungutes Gefühl, aber ich beobachte das erstmal so weiter.
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 25 Juni 2023, 16:35:39
Hm, leider hielt die Freude jetzt nicht ganz so lange :'( Hatte schon ein ungutes Gefühl...

Also momentan wird der Transceiver gar nicht mehr erkannt. Ich hab leider keine Idee für richtig sinnvolle Schritte. Muss ja irgendein Hardware-Problem sein?

Meine Ideen, was ich versuchen könnte:
- diesen großen Kondensator C1 tauschen
- den Transceiver ablöten von CC1 und auf CC3 wechseln
- nochmal Transceiver austauschen?? (Ist da irgendwas kaputt, was dann Transceiver auf CC1 killt??)
- den Maple ablöten und austauschen. Aber den runter zu löten ist totaler Mist (zumindest für mich). Also würde ich eigentlich nur machen wollen, wenn ich weiß, dass es wirklich an dem liegt.

Also irgendwie alles keine tollen Ansätze. Verzweiflungstaten. Hat da von euch vlt. jemand noch bessere Ideen oder kann sagen, dass eine der genannten vlt. doch sinnvoll erscheint?

Danke euch
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 26 Juni 2023, 19:43:26
Hallo VBS,

also ich kann Dir nur die Standardvorgehensweise empfehlen:
1. mit Durchgangsprüfer jede Leitung vom Maple zum CC3 prüfen. Mechanisch i.O.?
2. Mit Oszi sich die Signale anschauen und auf Anomalitäten prüfen (sind sie überhaupt da?)
3. Betriebsspannung im Betrieb prüfen. keine Aussetzer ? Netzteil?

Des Weiteren hast Du ja das Modul schon neu verlötet, probiere auch die Maplekontakte neu und sauber zu verlöten
Auf Deinem Foto kann ich sehr wahrscheinlich (Bildqualität!) eine kalte Lötstelle erkennen:

Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 01 Juli 2023, 09:57:44
Viellecht erleichtert so was auch die Diagnose:
Using a Raspberry Pi Pico as a Logic Analyzer with PulseView (https://www.hackster.io/markkomus/using-a-raspberry-pi-pico-as-a-logic-analyzer-with-pulseview-e12543)
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 01 Juli 2023, 13:54:26
Ach, ja cool, auch sehr interessant. Gibt ja auch recht günstige "Hosentaschenoszis" (wohl ohne Logic Analyzer):
https://de.aliexpress.com/item/1005005384160294.html?spm=a2g0o.productlist.main.5.ff0154ad5FHiCi&algo_pvid=1ca31e32-9d4c-452b-b5ff-29546334db4b&algo_exp_id=1ca31e32-9d4c-452b-b5ff-29546334db4b-2&pdp_npi=3%40dis%21EUR%2184.32%2139.63%21%21%21%21%21%402145274c16882066744834226d0744%2112000032832991675%21sea%21DE%21753341655&curPageLogUid=rMMy7xIOM2I4

Weiß aber nicht, was das taugt...

Aber tatsächlich hab ich sogar ein einigermaßen ordentliches Oszi und auch nen günstigen Logic Analyzer. Hab ich auch schon rausgekramt, angeschlossen und Software installiert. Ich komme nur momentan einfach zeitlich nicht dazu, da weiterzumachen  :'( Mir fehlt da ein bisschen die Erfahrung und ich hab es ewig nicht gemacht, darum werde ich da ein bisschen Zeit für brauchen...

Aber geht weiter, sobald ich kann. So schnell geb ich nicht auf!  ;)
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 09 Juli 2023, 11:51:33
So, da bin ich wieder...

Also, ich hab das jetzt sowohl Oszi als auch Logic Analyzer in Betrieb genommen. Mich wieder mit Bedienung und co. auseinandergesetzt. Hab zum Messen ein paar Fädeldrähte an die Messpunkte angelötet (macht man das so?). Ich konnte dann auf beiden Geräten auch die Signale sehen und auch mit dem Logic Analyzer das SPI dekodieren. Sah alles gut aus.

Die Sache ist: Das Problem tritt (momentan) einfach (wieder) nicht mehr auf und ich konnte den Fehlerzustand gar nicht analysieren :( Hab es jetzt dutzende Mal probiert mit PowerCycle und USB-Kabel rein/raus und im Moment passiert es (wieder) nicht mehr. Also ist komisch. Einzige Erklärung wäre, dass ich beim Rumlöten mit dem Fädeldraht irgendwas repariert habe. Keine Ahnung, wie wahrscheinlich sowas ist, aber ich hab keine bessere Erklärung.
Aber ist wieder mal ein nicht zufriedenstellendes Ergebnis... mal gucken, wie es weitergeht. Werde beobachten...
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 10 Juli 2023, 16:28:42
Das mit der kalten Lötstelle hattest Du gesehen? Geprüft?
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 10 Juli 2023, 18:10:54
Also eigentlich war ich der Meinung, davor schon alle Punkte einmal neu verlötet zu haben. Faszinierend, dass du da überhaupt was erkennst auf dem Bild ;)

Ich hab nochmal ein neues Bild gemacht. Leider wieder etwas verwackelt. Aber kannst gern nochmal sagen, ob dir da noch was auffällt, danke!
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: juergs am 10 Juli 2023, 20:17:58
So lange es geht.... 8)
Sieht von der Lötung her besser aus. Leider sieht man auf dem Bild und dem Winkel nur die Hälfte der Lötstellen. Provozieren kann man das Verhalten meist per Kältespray....

Vielleicht war es das schon?
Mehr ist per Ferndiagnose einfach nicht möglich ...

;)  ;D
Titel: Aw: Selbstbau CUN (MapleCUN)
Beitrag von: vbs am 10 Juli 2023, 20:36:30
Nach dem Neulöten des Maple ging es ja kurz und dann einen Tag später aber erstmal gar nicht mehr. Also passt alles nicht so richtig zusammen 8)

Na egal, danke erstmal. Momentan scheint es sehr stabil tatsächlich.