Hauptmenü

Incoming

Begonnen von RichardCZ, 07 Mai 2020, 14:55:18

Vorheriges Thema - Nächstes Thema

Beta-User

#15
[OT @papa]
Ich habe seit langem ein paar Blue Pill hier rumliegen, aber schon das flashen des Bootloaders war irgendwie "na ja", außerdem haben meine alle den "USB-resistor-bug" weswegen das "normale flashen" via USB nicht klappt (bzw. nicht stressfrei; ich weiß leider nicht mehr, wo die Fundstelle zu den Details ist).

Habt ihr denn bessere Erfahrungen gemacht? Ich kenne nur die Haltung von @Ranseyer dazu, und der schwört auf Maple Mini...

(Ich habe nur einen MapleCUN im Einsatz und der läuft halt... Sonst nix produktives, bisher konnte ich die MySensors-Nodes immer so stricken, dass mehr Power als ATMega32 nicht nötig war ::) . Hatte eigentlich vor, mit den Blue Pill "irgendwas an der Heizungstherme" zu machen, kannte aber damals "den Unterschied" noch nicht und war mal wieder Schwabe...).



Back to topic:

Die wesentliche Quelle zu STM32@Arduino ist stm32duino.com, da gibt es auch ein Wiki: https://github.com/stm32duino/wiki/wiki/Getting-Started
Zu den Boards samt Bezeichungen habe ich das hier gefunden, da steht auch etwas mehr zum flashen: https://theta.eu.org/2018/12/20/stm32.html. Irgendwo in den Untiefen des INet gab's auch mal eine Seite mit noch viel mehr Varianten von dem Zeug, aber eigentlich sollte das erst mal reichen...
Edit: noch mehr gab's z.B. hier: https://stm32-base.org/boards/, zum "Resistor"-Thema steht da auch kurz was: https://stm32-base.org/boards/STM32F103C8T6-Blue-Pill (irgendwo gab's 'ne Anleitung, wie man den zu hohen Widerstand "außen vorbei" mit einem passenden Widerstand brücken kann).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

papa

[OT@Beta-User]
Ich nehme zum Flashen grundsätzlich nen ST-Link. Damit gibt es keine Probleme.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Beta-User

Zitat von: papa am 08 Mai 2020, 16:42:56
[OT@Beta-User]
Ich nehme zum Flashen grundsätzlich nen ST-Link. Damit gibt es keine Probleme.
::) ... da hat wohl mal wieder einer mehrfach am falschen Ende gespart... (Wobei das Vorgehen den Vorteil hat, dass ich zwischenzeitlich besser verstehe, wie diverse MCU's ticken 8) ...)

Ein Link bzgl. des Resistor-Problems: https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Flashing-Bootloader-for-BluePill-Boards

Im Moment liegen die bei mir auf der Seite, aber ich meine, dass das flashen über A9/10 (was man für den BL eh braucht (?)) am Ende auch kein Problem war, auch wenn das schon wieder so lange her ist, dass ich mich an die Details nicht mehr erinnere. Auf die Schnelle müßte es aber diese Methode gewesen sein: https://maker.pro/arduino/tutorial/how-to-program-the-stm32-blue-pill-with-arduino-ide. Die Seite ist btw. auch ganz gut, weil da das komplette PIN-Layout enthalten ist.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RichardCZ

Meinungen zum Black Pill?

https://de.aliexpress.com/item/4000807291937.html?spm=a2g0o.productlist.0.0.74d65bbcPBoXuV

128KB Flash, angebl. verbesserte Version des BluePill (keine Resistor Probs) - 5V direkt verbunden haben sie alle - auch Maple.
Abgesehen davon hat der Black Pill auch KÖNNEN und "coprozessor einheit speziell verwendet für schwimm punkt betrieb"  ;D

(KÖNNEN = CAN) - hat länger gedauert bis ich das kapiert habe.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Beta-User

...ich hatte bisher nur Maple Mini und Blue Pill in der Hand.

Meine _persönliche_ Meinung als Schabe: Das sieht gut aus...
(Was die "Capabilities" angeht, unterscheiden sich die Dinger vermutlich nicht: Die "Blue Pill", die ich bisher in der Hand hatte, haben z.B. auch alle die 128k, letztlich ist es vermutlich ähnlich wie bei den gängigen Arduino-Clonen: Es kommt nur auf den Prozessor an, und der ist in fast allen Fällen derselbe. Wenn nicht, sieht man das sofort am Preis ;D ...).

Aber wie in anderen Fällen auch: Falls jemand ein Board designed (bzw. falls es schon eines gibt), ist das in der Regel für ein Chipset/Board, das der Layouter bereits kennt. Und die Blue Pill und der Maple Mini sind _nicht_ Pin-kompatibel, was wohl mit ein Grund ist, dass der betreffende Prozessor fast ausschließlich in der Maple Mini-Variante hier bei den Usern verbreitet ist. Ich würde daher den Schritt in diese Richtung dann gehen, wenn du selbst das "Standard-MySensors-Board" für Black Pill+CAN-Transceiver (oder PJON (!!)) layouten willst.
Sonst wäre es m.E. zu empfehlen, eher bei dem "traditionellen" Maple Mini zu bleiben (ist mit ziemlicher Sicherheit derselbe Prozessor).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Gisbert

Zitat von: Beta-User am 08 Mai 2020, 17:23:28
Meine _persönliche_ Meinung als Schabe: Das sieht gut aus...
Ich hab vermutet, dass es etwas sehr Spezielles mit den Schwaben auf sich hat, dass es aber gleich so schlimm ist ;D

Trotzdem viele Grüße
Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

KernSani

Zitat von: Gisbert am 08 Mai 2020, 19:22:15
Ich hab vermutet, dass es etwas sehr Spezielles mit den Schwaben auf sich hat, dass es aber gleich so schlimm ist ;D

Trotzdem viele Grüße
Gisbert
Ein echter Schwabe würde nie sagen ,,Das sieht gut aus", er könnte sich maximal zu einem ,,ned schlecht" hinreißen lassen, also muss die Schabe wohl korrekt sein :-D


Kurz, weil mobil....
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Christoph Morrison

Zitat von: Gisbert am 08 Mai 2020, 19:22:15
Ich hab vermutet, dass es etwas sehr Spezielles mit den Schwaben auf sich hat, dass es aber gleich so schlimm ist ;D

Als Exilbadener kann ich nur sagen: Einsicht ist der erste Schritt zu Besserung.

RichardCZ

Das Filzknäuel wird auch immer größer...

Dieses "Axago Teil" da ist ein USB <-> RS485, der tut auf Linux Seite, jetzt muss ich mal Versuch/Irrtum starten um das mit einem GW zu verbinden.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Beta-User

???
Was willst du mit einem RS485-Seriell/USB-Konverter? Du brauchst einen zweiten Arduino, der das, was via RS485 reinkommt in etwas "umwandelt", das 00_MYSENSORS.pm versteht... (RS485=MySensors-Interne Kommunikation, 9600 Baud über AltSoftSerial, USB=112k Baud über Serial(0). Mit den "nackigen" RS485-Daten fängt das IO-Modul nix an ;) . (Wir könnten versuchen, dem das beizubiegen, aber wegen der paar Cent lohnt das nicht, außerdem müßten wir ein weitere Art des Datenpuffers einbauen, um Kolissionen zu vermeiden...).

Auf den Arduino gehört dann ein bestimmter Sketch: https://www.mysensors.org/build/rs485#example-serial-gateway
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Gisbert

Zitat von: RichardCZ am 09 Mai 2020, 16:19:07
Das Filzknäuel wird auch immer größer...
Hallo Richard,

ich kann die Argumente gegen Wlan verstehen, a cable is a cable is a cable. Wenn man überall Kabel der richtigen Qualität liegen hat, ist das natürlich eine andere Frage.

Mit einem ESP8266 wären die Anzahl der Bauteile signifikant niederiger. Je nachdem welche Bauteile man nimmt, ist auch schon ein 230V-Anschluss drin (z.B. Shelly, Sonoff, Eigenbauten --> Papa Romeo und andere) oder man benötigt etwas, was 5 VDC bereitstellt. Verschweigen möchte ich nicht, dass man bei vielen Geräten ein gutes Wlan-Netzwerk benötigt. Ausfälle hatte ich bisher so gut wie keine, und wenn, dann haben die sich gleich zu Beginn gezeigt, was vermutlich auf schlechte Hardwarequalität eines Klons beruht, ein schlechtes Korn ist immer mal dabei.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

Zitat von: Gisbert am 09 Mai 2020, 17:52:36
die Anzahl der Bauteile signifikant niederiger.
Das ist - sorry - Unsinn! (Man denke nur an Netzteile, die man sich mit einer zentralen Versorgung parallel zum Signalkabel SPAREN kann - Schabe sei gegrüßt! (Wer braucht schon doppelte U?!?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Gisbert

Zitat von: Beta-User am 09 Mai 2020, 18:09:34
Das ist - sorry - Unsinn! (Man denke nur an Netzteile, die man sich mit einer zentralen Versorgung parallel zum Signalkabel SPAREN kann - Schabe sei gegrüßt! (Wer braucht schon doppelte U?!?)

Hallo Beta-User,

Oje, da habe ich aber einen Nerv getroffen, hoffentlich beruhigt er sich wieder.

Zurück zur Sache, dieses Argument ist natürlich richtig, wenn man die Spannungsversorgung zentral macht. Letztzlich kommt es auf die individuellen Bedürfnisse jedes Einzelnen an.

Bei den meisten steht nicht ein Plan für das Gesamtkonzept am Anfang, sondern man fängt mit etwas an und dann wuchert das System vor sich hin, und es werden Sachen eingebaut, nicht weil es man benötigt, sondern, weil es diverse Sensoren gibt, der Spiel- und Basteltrieb siegt.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

RichardCZ

Zitat von: Beta-User am 09 Mai 2020, 16:47:04
Was willst du mit einem RS485-Seriell/USB-Konverter?

Spannen.

Der zweite Arduino ist auf den Bildern - noch verpackt - auch zu sehen.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Beta-User

Ok, den 2. Arduino habe ich wohl übersehen, mir ist nur aufgefallen, dass keine der "typischen" MAX485-Boards zu sehen waren ;D .

Nette Idee, den Traffic auf auf der RS485-Seite mal anzusehen. Vermute, da sieht man im Prinzip genau dasselbe wie das, was am GW "hinten rauskommt". Für nRF24 habe ich das auch gemacht - per serieller Konsole an einer "Repeater"-Node, aber da bekommt man natürlich auch nur die dekodierten Daten (und einen ganz guten Eindruck, welche Node wann was mit welcher anderen spricht.). Btw. als Merkposten: Man kann @MySensors auch Node2Node-Kommunikation umsetzen. Ist zwar in der Regel "hartvercoded", aber irgendwo meine ich sogar mal was gesehen zu haben, das das konfigurierbar macht.

Zu dem Konverter noch: Du kannst den+Arduino+MAX48x auch auf eine weitere Art verkabelt für FHEM nutzen. Das Stichwort wäre "HomeMatic wired" in Verbindung mit "homebrew" oder kurz "HBW" für "homebrew wired". Gibt einen exzellenten Support dafür hier im Forum (wie auch zur "funkenden Schwester" AskSin++, für das du dich gerne vertrauensvoll u.a. an @papa wenden kannst)! Beides haben einige Nutzer hier ebenfalls seit Jahren zur vollsten Zufriedenheit im Einsatz.



@Gisbert:
Wir sollten das ggf. an anderer Stelle ausdiskutieren, aber deine Ausführungen hier sind sehr treffend:
Zitat von: Gisbert am 09 Mai 2020, 20:42:53
Bei den meisten steht nicht ein Plan für das Gesamtkonzept am Anfang, sondern man fängt mit etwas an und dann wuchert das System vor sich hin
Genau! In den allermeisten Fällen wollen die Nutzer von ESP8266 eine "schnelle Nummer" ohne große Verbindlichkeiten und wundern sich dann irgendwann, wenn aus Spaß "Ernst" wird und man den Tiger bändigen muß.
Das ist auch legitim, aber so ziemlich das Gegenteil von dem, was RichardCZ hier zu Beginn als Zielvorgabe geschrieben hatte (ganz abgesehen davon, dass er ganz eigene Vorstellungen und Pläne hat, wie man den Tiger FHEM "domestizieren" sollte).

Ich bitte daher um Verständnis, dass ich _vor diesem Hintergrund_ wirklich keine Lust habe, hier Grundsatzfragen der Hardwarekonzeption zu diskutieren.

Du bist herzlich eingeladen, einen eigenen Thread hier aufzumachen und provokativ die Frage zu stellen, ob MySensors im Jahr 2020 noch eine Daseinsberechtigung hat bzw. ob sich die Beschäftigung damit lohnt, wenn man weiß, wie man einen ESP8266 dazu bewegen kann, beliebige Daten per MQTT an FHEM zu senden. Wenn du selbst ernsthaft MySensors ausprobieren willst, schicke ich dir gerne auch kostenfrei ein paar MAX485-oder (funktionierende) nRF24L+-Module zu, ich müßte noch welche im Keller haben...

Btw.: Mit NRF52 gibt es auch auf der MySensors-Seite eine "one-in-all"-MCU, mit der man "langzeitbatteriefähige" Funklösungen realisieren kann ;) . Man muß den Tiger nur bändigen... (der ist aber zahmer als der mMn. schlecht designte ESP8266!).

Damit bitte ich diese Diskussion über ESP8266 als Alternative _hier_ zu beenden!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files