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_MAICOWas für ein Funkprotokoll ist das?

Stellt
#define HAS_UART 1CUL 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_W5500W5500 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
CUL Kommando "L" ...
#define HAS_MAICOWas 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/).

Stellt
#define HAS_UART 1CUL 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.

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.

Ist WIZnet W5100 durch W5500 ersetzbar?
#define HAS_W5500W5500 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.

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
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
Zitat
Nimm bitte Rücksicht auf diejenigen, die den MapleCUL/MalpeCUN schon im Einsatz haben

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

Ich hab nochmals nachgelesen:
Zitat
RX1/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
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.

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:
Zitat
dfu-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
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.

-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
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
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
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
  -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?

  -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
Zitat
Aber 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
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.

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
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)


Zitat
define 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


Zitat
2017.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
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.

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
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
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  :)

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
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
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
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.

Zitat
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.
Danke! Die Anbindung via USB funktioniert:
define myRemoteHmUART HMUARTLGW /dev/ttyACM1
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.

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
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
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
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
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
@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
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
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
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
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.

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.

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
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
@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
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
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
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
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
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,

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
...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,

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
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).

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
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,
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
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
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.

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,
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
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
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
Zitat
Auch 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.

Zitat
Abseits 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,

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
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.

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
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
Zitat
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.

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
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
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
Zitat
zusä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
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.

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:
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??
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,
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.

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...

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,
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
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.

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
Ich will da nicht zu viele Varianten reinbringen.

Ok, das kann ich verstehen.

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.

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:

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
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
Zitat
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.

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...

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...

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...

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
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
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
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
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
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
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,
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
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,
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.

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
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: BbCFiAZNEkGMKLUYRTVWXeflptxzDa 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?

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,
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.

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
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: BbCFiAZNEkGMKLUYRTVWXeflptxzDa 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
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.

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

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,
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.

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,
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
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
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,
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.

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
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
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
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?


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
Zitat
Ich 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
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
Gibt es seit heute wieder.

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


Zitat
Wie 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,
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"...

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
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,
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,
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 0123Der 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
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
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,
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: Baerli73 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
Zitat
make[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,
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,

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:
Zitat
1: /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:
Zitat
arm-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 ...

Zitat
Der 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
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
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
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
- 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.

- 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.

- 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|pcrid|76709463183|kword|0868bm15c0001e|match|p|plid|&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: Baerli73 am 07 Juni 2017, 21:45:07
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: Baerli73 am 07 Juni 2017, 22:04:51
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
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
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
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 ...
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
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.

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
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
Zitat
The 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
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:
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

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  ;)

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  ;)).

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.

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.

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)  :-\

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.

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
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-utildfu-util installiert, aber mit
dfu-util --listwird 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:
Zitat
artin@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

Gruß PeMue
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.



Zitat
Dann 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


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
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
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:
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
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.

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
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
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
... 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
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,

Zitat
stm32flash 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:

Zitat
Allow 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
Zitat
Perpetual 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
Zitat
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.

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

Zitat
Windows 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,

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.

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.

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.

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,

Zitat
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 

... 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 ...  ;)

Zitat
Mittlerweile 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
... 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!) :

Zitat
Arduino: 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?
Zitat
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...

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,
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:
Zitat
Messages 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.

Zitat
2017.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:
Zitat
Internals:
   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:

Zitat
CUL
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
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
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
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.

@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
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,
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
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.

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
Zitat
kannst 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
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,

Zitat
Magst Du bitte testen und Feedback geben?
Ja, gerne.

Zitat
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.
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.

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 ...
Zitat
On "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
Zitat
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.
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:

Zitat
V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_00 (F-Band: 868MHz)


Zitat
Deine 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
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.

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
Zitat
MapleCUNx4_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
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,

-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\winDort 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
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)

Zitat
The 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
Zitat
man 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,

Zitat
ich 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:
Zitat
Selbstbau 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
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,

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
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
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
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
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.

Zitat
b) was mit den ständigen Reconnects anfangen kann
Windows? Antwort #391

Zitat
c) ein erneutes flashen etwas bringen kann
Es ist nicht auszuschließen …
## Changelog:
#### 1.25.00
- Improve hardware autodetection

Zitat
d) 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 ?

Zitat
define 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:
Zitat
Internals:
   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,
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:
Zitat
2017.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?):
Zitat
define 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
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

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.

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
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
... 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,

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.

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
   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

   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
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
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
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
Also 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
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
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.

Zitat
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.
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,
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
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,
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.binJetzt 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
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
Zitat
Ich 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...)

Zitat
Time 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
Hmm, 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
Zitat
Nein, 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
- 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
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)

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

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.

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



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


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
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
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
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
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
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:

Zitat
rwxr-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

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
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
Zitat
die 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
Zitat
Ausser 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 SendungIst 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
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
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
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
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" !

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
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.


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.


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
- 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.

No, 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?

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
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?

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
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
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
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,

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.hexfindet 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
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
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
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
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,

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
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
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
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
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
Zitat
OK, 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
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
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.

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
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)

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,

Zitat
nanoCUL 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
@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.

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:

Zitat
Ist der Debug Uart ganz normal der Tx*/RX* auf dem Maple Mini?
Ja.

Zitat
Da 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
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.

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

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
Zitat
wie 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.

Zitat
Internals:
   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
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@115200Die 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
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,
Das 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 :( .
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

Zitat
Was 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.gitund 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
Zitat
OK, 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
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 mCUN2ersetzen.

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
Zitat
Hi,
Bilder! Bitte durch ein
Code: [Auswählen]

list mCUN2

ersetzen.
erledigt

Zitat
set 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: fhem-hm-knecht 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:8dBfest 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
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
Zitat
Cannot 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)
Beitr