FHEM Forum

Zitat von: Beta-User am 06 Mai 2020, 09:48:47
:) Da bin ich ja mal gespannt. Hast du jetzt nur RS485-Bauteile drin oder auch "Funker"?

Um die Frage in der richtigen Umgebung zu beantworten: Nur RS485 bislang - ich will kein Funkzeug (vor allem wegen Zuverlässigkeit), vermutlich probiere ich auch CAN - sobald ich alles ein wenig mehr konzeptionell auf die Reihe bekomme. Die ersten Ardino-Spielsachen sind angekommen, breites Elektroniksortiment liegt auch vor.
Der erste AM2320 I²C röchelt auch schon.

Und dafür braucht es nen neuen Thread?  >:(

Ja, neuer Thread ist völlig i.O. Ich hatte eine Frage gestellt, und in diesem Forenbereich ist die Antwort on topic, am gestellten Ort war sie OT...

Außerdem kann man die Frage stellen, ob das von anderer Seite auch angefragte CAN-Zeug noch in den RS485-Thread gehört oder nicht (war nahe dran, das positiv zu entscheiden, aber das ist "mein" Thread...). Da beklagt sich auch keiner.

Wenn also ein Anfänger@MySensors hier seine Fragen stellen will und einen eigenen Thread aufmachen, um "seine" Themen zu besprechen, ist das m.E. ok (@Ranseyer darf mich gerne korrigieren, wenn er das anders sieht). Meine Erwartung ist, dass vorab der Starter-Guide gelesen wird und etwas Grundlagenwissen zu FHEM vorhanden ist. Dieser TE hier hat den "Starter-Guide" im Wiki definitiv gelesen (Danke an der Stelle für den Hinweis auf den zwischenzeitlich korrigierten Typo...), den Rest "werden wir sehen..."  ::) .

Kleiner Hinweis am Rande: Hier in diesem Forenbereich bin ich Moderator und bitte darum, das "F" in FHEM zu beachten (gilt in alle Richtungen).

Auch wenn es OT ist:
Ich finde viele "kleine" Threads besser als ein Großer, wo dann auch viele Probleme parallel bearbeitet werden ... einen Thread mit 30+ Seiten liest sich doch keiner mehr Durch ...

Der winzigste "Kritikpunkt" wäre, das man einen Verweis auf den Thread, von woher es kommt, hätte mitgegeben könnene ...

Zitat von: Wernieman am 07 Mai 2020, 15:54:06
Der winzigste "Kritikpunkt" wäre, das man einen Verweis auf den Thread, von woher es kommt, hätte mitgegeben könnene ...

Das ist durch den Link über dem Zitat gegeben ;)

Korrekt, auch wenn das im Moment wenig zur Sache tut... (Außer vielleicht die Andeutung liefert, dass Richard die Teile, die nicht die FHEM-Module im Sinne von Code-Analyse, sondern die eigentliche Hardware oder die Modulfunktionalität betreffen, ggf. hier besprechen will (?). Aber da lasse ich mich auch überraschen, in welche Richtung das gehen soll.)

Ansonsten kann man geteilter Meinung sein, was "Mega-Threads" angeht. Ich für meinen Teil bin froh, dass der "Integration von MYSENSORS..."-Thread diesem Bereich hier gewichen ist und man daher manches (hoffentlich) leichter wiederfindet, andererseits ist das "CAN"-Thema eigentlich nichts spezielles, es wird eben nur ein etwas anderer Transceiver genutzt, Rest ist identisch, insbesondere sind die ab dem Transceiver bestehenden Fragen mMn. 1:1 identisch und die Sketche nur geringfügig anders. Da macht ein getrennter Thread nicht unbedingt Sinn.

---

Zurück zum Ausgangspost:
Das Breakoutboard sieht btw. gut aus! War immer zu knausrig, sowas zu besorgen, kann aber jedem Einsteiger nur empfehlen, das auch mit auf die Einkaufsliste zu setzen! Das dürfte Verkabelungsprobleme deutlich minimieren... ;D .

Noch was für die Einsteigereinkaufsliste: Für die RS485-Variante (auch@CAN) finde ich einen Arduino Pro Micro (ATMega32U=2 hardware-serial-Schnittstellen) empfehlenswert. Nicht für das erste GW, aber wenn die ersten Tests erfolgreich sind und klar ist, was aus der seriellen Schnittstelle eigentlich rauskommen soll. Sketch hatte ich an anderer Stelle irgendwo gepostet.

ZitatDas Breakoutboard sieht btw. gut aus! War immer zu knausrig, sowas zu besorgen, kann aber jedem Einsteiger nur empfehlen, das auch mit auf die Einkaufsliste zu setzen! Das dürfte Verkabelungsprobleme deutlich minimieren... ;D .

Edit: In der irrigen Annahme, dass ein Breadboard ein Breakoutboard ist, Edit Ende war bei mir Edit: ein Breadboard Edit Ende in der Konzeptionsphase ein Durchbruch gegenüber einem fliegenden Aufbau mit Klemmen und/oder verdrillten Leitungen, da war das Scheitern vorprogammiert.

Viele​ Grüße​ Gisbert​

Zitat von: Gisbert am 07 Mai 2020, 16:32:01
Breadboard war bei mir in der Konzeptionsphase ein Durchbruch...

Am besten ist, man hat beides. Ein Breadboard und ein Breakoutboard.  ;)

---

Ich habe den Thread hier aus mehreren Gründen aufgemacht. Beta-User weiß dank unserer PMs schon seit längerem, dass ich das "vegetative Nervensystem meines Hauses" mit MySensors realisieren möchte und meinte es wäre auch an der Zeit einige Fragen von mir öffentlich zu diskutieren, weil dann eben auch andere was davon haben.

Da sich nach Erhalt der Hardware meine MySensors Ambitionen nicht mehr auf der rein theoretischen Ebene befinden und ich stolz war, dass mein erster Sensor tut, sah ich eine gute Gelegenheit hier mein "Coming out" zu haben. Ansonsten sehe ich das so, dass Bastelecke/MySensors eben über MySensors HW/SW ist und nicht über Perl.

=> also hier bin ich Neuling und Ratsuchender.

---

RS485/CAN ist für mich ein zentrales Thema. Wenn ich mit einem CAN Receiver einen MAX485 drop-in ersetzen kann, so dass sein Ausfall nicht den gesamten Bus mit in den Abgrund zieht, mache ich das. Mit MCP2551 habe ich ein wenig Bauchschmerzen. weil eben schon seit 2014 EOL (siehe http://ww1.microchip.com/downloads/en/DeviceDoc/20001667G.pdf das dicke fette "Not recommended for new designs, please use MCP2561") - aber irgendwie finde ich keine 2561 shields und selbst Leiterplatten ätzen und SMD Flöhe draufkleben wollte ich jetzt nicht.

Eine zeitlang dachte ich, ich verwende 2515 direkt am SPI und habe ein 1MBit MySensors netzwerk, aber dann dachte ich, dass ich nicht gleich mit SciFi anfangen muss. :-)

Die ersten Gehversuche/Herumstochern mache ich mit RS485, also ist noch Zeit bevor ich irgendwelche konkreten Hardwareentscheidungen treffe.

Mein vages Ziel ist es ein "Kästchen" zu konzipieren was pro Zimmer zum Einsatz kommt und dort grundlegende Daten liefert (Temperatur, Luftfeuchte, Luftdruck Lichtsensor, Lautstärkesensor, ... k.A. was noch alles - aber wennschondennschon) und davon mache ich dann eine Kleinserie die eben am RS485/CAN Bus hängt und o.g. vegetatives Nervensystem des Hauses darstellt. ggf. kommen noch ein paar GWs hinzu - je nach Bedarf bzw. hierarchischem Layout und das dann an einen FHEM/HoBo Server.

Definitiv darf der Ausfall so eines "Kästchens" nicht dazu führen, dass das ganze Sensornetzwerk die Grätsche macht. Der Ausfall eines GWs auch nur den daran hängenden "Ast".

Zitat von: RichardCZ am 07 Mai 2020, 17:16:00
Am besten ist, man hat beides. Ein Breadboard und ein Breakoutboard.  ;)

Ich erhöhe: Am besten, man hat mindestens zwei Breakoutboards und einige Breadboards ;D ...
Das Breakoutboard hat so vom Bauchgefühl her vor allem den Vorteil, dass man die Stromversorgung einzelner Sensoren definierter verkabeln kann, auf meinen Breadboards (ohne die ich schon lange nutze und ohne die ich definitiv verloren gewesen wäre!) wird das schnell wirr, vor allem, wenn man mehrere SPI-Devices angeschlossen hat (alle anderen Transceivern nutzen SPI zur Kommunikation mit der MCU...).

Zitat=> also hier bin ich Neuling und Ratsuchender.

Gerne!

ZitatRS485/CAN ist für mich ein zentrales Thema. Wenn ich mit einem CAN Receiver einen MAX485 drop-in ersetzen kann, so dass sein Ausfall nicht den gesamten Bus mit in den Abgrund zieht, mache ich das. Mit MCP2551 habe ich ein wenig Bauchschmerzen. weil eben schon seit 2014 EOL (siehe http://ww1.microchip.com/downloads/en/DeviceDoc/20001667G.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/20001667G.pdf) das dicke fette "Not recommended for new designs, please use MCP2561") - aber irgendwie finde ich keine 2561 shields und selbst Leiterplatten ätzen und SMD Flöhe draufkleben wollte ich jetzt nicht.

U.a. deswegen ist die Antwort hier etwas länger ausgefallen:
https://forum.fhem.de/index.php/topic,84814.msg1051315.html#msg1051315

Auch wenn die Anwendungsempfehlung des Herstellers eine andere ist: Lieber völlig outdated EOL-Hardware einsetzen, die für den beabsichtigten Zweck gut paßt, wie den Versuch zu unternehmen, das "zu modern" zu machen. Ich bin zwar auch e-Technisch nur sowas wie ein fortgeschrittener noob, aber vom Bauchgefühl her ist "echtes CAN" eher wie I2C (und SPI ?) für kürzere Strecken designed, jedenfalls, was hohe Datenraten angeht. Das treibt bei längeren Strecken den Energiebedarf hoch, weil man vermutlich kleinere Widerstände braucht, um den Bus in einer "stabilen 0" zu halten und trotzdem ausreichend deutliche Flanken (ohne Reflexionen) zu bekommen. Was mir im Moment fehlt ist ein Gefühl dafür, wann (ab welcher Kabellänge etc.) Schluß mit lustig ist...

ZitatEine zeitlang dachte ich, ich verwende 2515 direkt am SPI und habe ein 1MBit MySensors netzwerk, aber dann dachte ich, dass ich nicht gleich mit SciFi anfangen muss. :-)

Für alle nochmal: Das ist jedenfalls derzeit mit MySensors nicht möglich, schlicht, weil es keinen "Treiber" für MCP2515@MySenors gibt. Kann man vermutlich schreiben, aber das ist dann eine ganz andere Diskussion.

Es gibt mind. noch eine andere Überlegung/verkabelte Variante, die aber mWn. nie über das Konzeptstadioum raus ist: pjong (?) oder so. Da wird direkt die serielle Schnittstelle der Arduinos genutzt... Wenn's wen interessiert, kann ich versuchen, den betreffenden Link im MySensors-Forum zu suchen. Aber ab da muß man dann selber klarkommen, ich mach' lieber einen auf "outdated hardware", die ich kenne 8) .

ZitatDie ersten Gehversuche/Herumstochern mache ich mit RS485, also ist noch Zeit bevor ich irgendwelche konkreten Hardwareentscheidungen treffe.

Mein vages Ziel ist es ein "Kästchen" zu konzipieren was pro Zimmer zum Einsatz kommt und dort grundlegende Daten liefert (Temperatur, Luftfeuchte, Luftdruck Lichtsensor, Lautstärkesensor, ... k.A. was noch alles - aber wennschondennschon) und davon mache ich dann eine Kleinserie die eben am RS485/CAN Bus hängt und o.g. vegetatives Nervensystem des Hauses darstellt. ggf. kommen noch ein paar GWs hinzu - je nach Bedarf bzw. hierarchischem Layout und das dann an einen FHEM/HoBo Server.

Definitiv darf der Ausfall so eines "Kästchens" nicht dazu führen, dass das ganze Sensornetzwerk die Grätsche macht. Der Ausfall eines GWs auch nur den daran hängenden "Ast".

Das ist völlig ok.

Wie per pm schon geschrieben: MMn. ist es für die "Raumnodes" eventuell interessant, einen Maple Mini (STM32F103, aber nicht Blue Pill) als MCU einzuplanen. Der hat für alles mögliche ausreichend Reserven, bei Bedarf 3 hardware-serial-Schnittstellen, ist teilweise 5V-tolerant... Er ist nur eben "etwas schwieriger" zu Programmieren und daher kein echtes Einsteigergerät wie ein Nano/Uno oder ein Pro Mini (und auch noch etwas schwieriger wie der schon erwähnte Pro Micro). Der kann dann sicher auch höhere Datenraten an Seriell (bzw. hat schon CAN-Funktionalität "on chip", aber auch das wäre (auch für die allgemeine MySensors-Gemeinde) Neuland...).

Grundsätzlich würde ich aber jedem RS485-Einsteiger raten, die "pure CAN-Transceiver"-Variante ernsthaft ins Auge zu fassen; leider findet sich z.B. im Datenblatt des TJA1051 (https://www.nxp.com/docs/en/data-sheet/TJA1051.pdf) nichts zur minimalen Datenrate, aber auch den Vorgänger gibt es noch zu kaufen... Von daher wäre mMn. Maple+TJA105x eine gute Basis; bei 56k sollten längere Strecken noch stressfrei gehen (die TJA1050 waren bei mir für einige Wochen mit ca. 50m Kabellänge im Echteinsatz, bis die MCP2551 da waren und die Datenrate wieder runter genommen wurde...).

---

Vielleicht noch hier OT der Hinweis: die mit Richards (und anderer Leute) Hilfe überarbeiteten Module haben ein paar neue features bekommen, und wenn es niemand außer mir und Richard testet, müssen eben die "Funker" damit leben, dass es gewisse Restrisiken gibt, wenn ich das nach bestem Wissen und Gewissen irgendwann einchecke...

Ich habe die leidige Erfahrung gemacht, dass meine Steckbretter und Jumperkabel zu billig waren: kontaktieren nicht immer sauber, sodass der Testaufbau irgendwie "gesponnen" hatte (Sduino hatte damals auch irrwitzige Frequenzen). Davon abgesehen lief es sehr gut (mein Hello-World-Sketch war der Distanzsensor).
In schwäbischem Stil sind mir die Dinger trotzdem zu schade wegzuwerfen  ;D

Viele Grüße
rob

... es hat mir keine Ruhe gelassen:

Zitat von: Beta-User am 07 Mai 2020, 18:07:22
Es gibt mind. noch eine andere Überlegung/verkabelte Variante, die aber mWn. nie über das Konzeptstadioum raus ist: pjong (?) oder so. Da wird direkt die serielle Schnittstelle der Arduinos genutzt... Wenn's wen interessiert, kann ich versuchen, den betreffenden Link im MySensors-Forum zu suchen.

Kurze Zusammenfassung:
Es gab vor ca. 3 Jahren einen Patch-Vorschlag, der allerdings - aus Gründen, die ich nicht kenne - keinen Eingang in die MySensors-Codebase gefunden hat. Es geht wohl um ca. 100 Zeilen Code, das wäre also vermutlich wesentlich einfacher zu integrieren/auf die aktuelle Codebasis@MySensors hin zu überarbeiten als z.B. ein SPI-Treiber für den MCP2515. Die (ziemlich kurze) Diskussion dazu im MySensors-Forum ist hier zu finden: https://forum.mysensors.org/topic/3977/transport-based-on-single-wire-pjon-protocol?_=1588922672916 (https://forum.mysensors.org/topic/3977/transport-based-on-single-wire-pjon-protocol?_=1588922672916)

Der eigentliche Transportlayer nennt sich PJON, Quelltext ist hier zu finden: https://github.com/gioblu/PJON (https://github.com/gioblu/PJON). Zu meiner großen Überraschung ist dieses Projekt aktuell gepflegt, der letzte commit ist grade mal ein paar Tage alt!

Was Längenbegrenzungen für Leitungen usw. angeht, habe ich das hier gefunden (https://github.com/gioblu/PJON/tree/master/src/strategies/SoftwareBitBang):

ZitatSoftwareBitBang is a software implementation of PJDL (Padded Jittering Data Link) (https://github.com/gioblu/PJON/blob/master/src/strategies/SoftwareBitBang/specification/PJDL-specification-v4.1.md). It supports simplex and half-duplex asynchronous serial communication for up to 254 devices over a single wire. The maximum length of the bus can reach between 800 and 2000 meters depending on the mode used. It is a valid alternative to 1-Wire because of its flexibility and reliability. Fault tolerance schemes can be easily implemented because communication pins can be configured at runtime. Take a look at the video introduction (https://www.youtube.com/watch?v=GWlhKD5lz5w) for a brief showcase of its features.

Ich habe jetzt nur kurz zusammengesucht, was auf die Schnelle hier relevant zu sein schien, aber vielleicht ist die Zeit für die Suche nach einem "besseren CAN-Chip" eventuell besser investiert, wenn wir uns zusammentun und PJON@MySenors ans laufen bringen?

Nachtrag: Da ist auch die Entwicklung@MySensors nicht stehen geblieben: https://github.com/mysensors/MySensors/pull/1278

Ich habe mich gestern Abend noch mit dem STM32F103 beschäftigt.

Das sieht interessant bis unglaublich aus. Im Vergleich zum Nano: praktisch gleiche Bauform, 1/3 des Preises, knapp 5x schneller, doppelt so viel EEPROM Speicher, 10x soviel RAM, 10 A/D Wandler statt 6, etc.

Wenn ich das recht verstanden habe ist das ein 32bit ARM (Cortex3?) - also komplett andere Mikroarchitektur, aber wird wohl mit ein wenig Aufwand von der Arduino IDE unterstützt.
CAN hat der auch gleich eingebaut. (Die Frage ist nur, unterstützt MySensors dann das?)

Dein Preisvergleich zum Nano hinkt; kommt immer drauf an, wo man was kauft...

Für eine ATMega328-Node würde ich z.B. keinen Nano nehmen, sondern einen Pro Mini-Clon, und den bekommt man im fernen Osten für irgendwas unter 2 Euro. Ein "vernünftiger" STM32F103 kostet etwa einen Euro mehr (der "Maple"). Bitte die Finger von den billigeren "Blue Pill" lassen, die sind teils schlecht designed (falsche Widerstände und so), das lohnt nicht!

Und nochmal: der C-Code des MySensors-Projekt weiß nicht, was CAN sein soll, ganz gleich, welche MCU man verbaut....

Mit PJON sollte aber auch ein Maple klarkommen ;) . (Der "kann" nämlich teils auch 5V).

Ernsthaft: Wir sollten das supporten, dass PJON vollends in den development-branch kommt, das sieht cool aus und ist ziemlich weit gediehen!
Vielleicht noch ein paar Anmerkungungen zu den Beteiligten da: tekka007 ist "der" Hardware-Interface-Mensch bei MySensors, wenn der das "in der Mache" hat (und ggf. ein bißchen support bekommt), dann wird das was, no doubt about it. Und der Hauptentwickler hinter PJON scheint auch weiter interessiert zu sein.
Beide Seiten haben so großes Interesse, dass man die Lizenzierungsfragen auch etwas genereller angegangen ist, das scheint einer der Haupt-Gründe zu sein, wieso das nicht schon seit Jahren "läuft".

Zitat von: Beta-User am 08 Mai 2020, 15:33:13
Dein Preisvergleich zum Nano hinkt; kommt immer drauf an, wo man was kauft...

Für eine ATMega328-Node würde ich z.B. keinen Nano nehmen, sondern einen Pro Mini-Clon, und den bekommt man im fernen Osten für irgendwas unter 2 Euro. Ein "vernünftiger" STM32F103 kostet etwa einen Euro mehr (der "Maple"). Bitte die Finger von den billigeren "Blue Pill" lassen, die sind teils schlecht designed (falsche Widerstände und so), das lohnt nicht!

Ist das hier so ein blue Pill"? https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino/233028113080
Hast Du konkrete Links zu den benamten Komponenten (z.B. zu so einem "Maple") damit ich dann auch mal ne authoritative Quelle habe wie das Dingens aussieht.

https://asksinpp.de/Grundlagen/STM32/

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

[OT@Beta-User]
Ich nehme zum Flashen grundsätzlich nen ST-Link. Damit gibt es keine Probleme.

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.

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.

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

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

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

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.

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.

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

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

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

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​

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.

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!

Zitat von: Beta-User am 10 Mai 2020, 07:55:23
sehr treffend: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).

OT: Noch eine Anmerkung, die zum Einsteigerleitfaden passt. Ich bin ja auch einer, der eine schnelle Nummer wollte (ich kam von pilight) und habe erst im Laufe der Arbeit gemerkt, was so alles möglich ist. Ich glaube, für die meisten FHEM-Nutzer ist dieser Ansatz normal. Sie kommen mit einem konkreten Problem, bauen dann aus (mit der Hardware, die sie gerade beherrschen) und spüren danach, dass es so nicht weitergeht.  Ich vermute auch, dass die Programmierung in Perl hier so gestaltet ist. Ein Profi (in Perl oder in Hausautomatisierung) denkt natürlich anders - aber das sind vermutlich die wenigsten. Ich habe zB mit 433MHz angefangen und fand das toll, bis mir der fehlende Rückkanal auf die Nerven ging. Inzwischen habe ich nur noch eine verlorene 433MHz-Dose, die ich zu faul bin auszutauschen. Also das ist ein ganz menschliches Verhalten. Ich würde aber die Leute nur dann drauf hinweisen wollen, wenn sie explizit nachfragen. Sonst lohnen Diskussionen nicht, da bin ich Deiner Meinung, das steigert nur die Popcorn-Produktion.

Zitat von: Beta-User am 10 Mai 2020, 07:55:23
Ok, den 2. Arduino habe ich wohl übersehen, mir ist nur aufgefallen, dass keine der "typischen" MAX485-Boards zu sehen waren ;D .

Ich weiß jetzt nicht welches MAX485 typisch ist, dachte diese mit den grünen Klemmen sind die typischen - jedenfalls ist da ein MAX485 drauf. (siehe markiertes Bildchen nochmal)

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

Bei mir werden seit Jahresanfang ziemlich extensive Umbauarbeiten an einem Haus geplant, die - so das Schicksal will - vor Weihnachten abgeschlossen sein sollen.
Da ist das Verlegen von Kabeln noch das Mindeste. Für "schnelle Nummern" bin ich zu alt und werde auch nicht jünger. Daher will ich mir für die Rente so wenig
technische Schuld aufladen wie möglich.

...

Moeller hat hier ein paar interessante Zahlen zu verschiedenen Bussystemen (einschl. Übertragungskapazität/Länge) und gibt Empfehlungen zu Kabeln ab, bzw. schon mehr als nur Empfehlungen: "zwingend abgeschirmt", verdrillt, etc. Habe ein paar Experimente veranstaltet, allerdings sind die vorhandenen Kabellängen (auf Rolle) "nur" 100m, also kann ich keine Aussagen zu 1200m treffen, aber das Oszi sagt der Unterschied verdrillt, geschirmt (noch nicht geerdet) und unverdrillt ungeschirmt ist eklatant.

Wozu meine Elektrotechnik-Kenntnisse nicht ausreichen ist die Empfehlung "die Kabelabschirmung nur an EINEM Ende zu erden" zu erklären. Ich dachte je mehr desto gut, aber scheint nicht der Fall zu sein.

ftp://ftp.moeller.net/DOCUMENTATION/AWB_MANUALS/h1569d.pdf

Interessanter Link :) . Enthält u.a. zu dem RS485-Thema eine ziemlich gute Zusammenfassung von allen möglichen, was wir in dem "Spezial-Thread" zur Busauslegung ventiliert hatten. Interessant, dass (kurze) Stichleitungen nur bei CAN vorgesehen sind und es da eine Begrenzung auf 32 TN gibt - das war mir neu.
(Wobei das auch bei RS485 steht, und der MAX487 kann afaik 128 TN... Vielleicht will mal jemand erst 33 und dann 129 MySensors-Nodes mit CAN aufbauen? Dann wissen wir, ob bis zu 253+GW-Nodes damit möglich sind ;D ).

Das mit dem "einen Ende" dürfte damit zusammenhängen, dass die Potentiale auf beiden Seiten unterschiedlich sein können, also "Erde" nicht gleich "Erde" sein muß. Und bei der Schirmung geht es ja "nur" darum, von außen kommende Signale möglichst abzuleiten - dafür reicht eine gute Verbindung auf eine Seite allemal aus...

Was die Stromversorgung und elektrische Auslegung insgesamt angeht, habe ich auf der Niederspannungsseite alles auf einer "Schiene" mit Ausnahme des GW. Das ist nur mit den beiden CAN/RS485-Drähten mit dem Rest verbunden. Aktorik ist - soweit vorhanden - ansonsten selbstredend galvanisch getrennt.

(Und sorry, ich hatte nur das "letzte" Bild vor Augen, nicht mehr das "Auspacken"-Incoming...)

Zitat von: Beta-User am 10 Mai 2020, 10:52:07
Das mit dem "einen Ende" dürfte damit zusammenhängen, dass die Potentiale auf beiden Seiten unterschiedlich sein können, also "Erde" nicht gleich "Erde" sein muß.

Meint Ihr vielleicht https://de.wikipedia.org/wiki/Erdschleife (https://de.wikipedia.org/wiki/Erdschleife)?

So - heute habe ich nochmal zugelangt und eine Halde weiterer Komponenten bestellt.
U.a. 2 x den Black Pill von RobotDyne, D/A Wandler, Feuchtigkeits- und Regensensoren, RFID Leser/Schreiber samt Karten und Chips, Ethernet-Shield für Arduino Nano
Hallsensoren, Joysticks, Kapazitative sensoren (Touch), Display (Grafik, Blau/Gelb), I2C IO Expander, Neigesensor, Lichtsensor. etc. pp

Spielkind halt. ;-)

 ;D das klingt lustig...

Hast du den auch schon FHEM-Devices angelegt bzw. anlegen lassen? Irgendjemand (einer!) hat ja meine neuesten Ergüsse runtergeladen...

(Ansonsten: Was ist mit UV-Strahlung, Infrarot-Temperaturmessung, Hochtemperaturmessung mit MAX6675, BMEx80 und den unvermeidlichen DS18B20...? Ein paar Näherungssensoren, TCRT5000? Oder MPR121? Fragen über Fragen für Spielkinder, und China ist soooo groß und weit  :P ).
Bevor du bei speziellen Dingen anfängst zu coden: Manches habe ich zumindest in experimentellen Varianten hier rumliegen, z.B. auch für diese RFID-Dinger (allerdings abhängig vom Readertyp). Das ist teils nicht ganz easy, meine mich erinnern zu können, dass man da Strings in Char-Arrays wandeln mußte u.ä..

OT:
Schade das es nicht nette "Sets" mit Sensoren gibt ... ;o)

Zitat von: Wernieman am 10 Mai 2020, 18:08:40
OT:
Schade das es nicht nette "Sets" mit Sensoren gibt ... ;o)

Wieviele Sensoren willst du denn in einem Set, reichen 45?

https://www.banggood.com/de/Geekcreit-45-In-1-Sensor-Module-Board-Starter-Kits-Upgrade-Version-Geekcreit-for-Arduino-products-that-work-with-official-Arduino-boards-p-1137050.html

Ähnliches gibt es natürlich auch bei eBay und Amazon aus Deutschland.

...das Problem bei den 45 dürfte nur sein, dass die Hälfte direkt in die Tonne gehört...

(Da fällt mir ein, dass ich noch so ein Wasserzählerprojekt mit einem gepulsten Laser fertigmachen wollte... ::) Habe auch so einen dusseligen mit den kleinstmöglichen roten Zeigerchen, bei dem diverse Varianten von Näherungssensoren und modifizierte TCRT500-Schaltungen nicht wollten  :( ).

(@RichardCZ: Falls es zu OT wird hier, darfst du das gerne äußern!)

Stimme Beta-User zu. z.B. die Wasser-Sensoren sind gleich .. Vergessbar.

ZitatDas mit dem "einen Ende" dürfte damit zusammenhängen, dass die Potentiale auf beiden Seiten unterschiedlich sein können, also "Erde" nicht gleich "Erde" sein muß. Und bei der Schirmung geht es ja "nur" darum, von außen kommende Signale möglichst abzuleiten - dafür reicht eine gute Verbindung auf eine Seite allemal aus...

erde sollte immer erde sein.  ;)
allerdings sind erdpotentiale an unterschiedlichen orten nicht identisch. erde gehört aber eher zum schutzkonzept einer anlage.
hier soll die versorgung ja "mitgeführt" werden. daher die abschirmung an der quelle der versorgung "anschliessen".

vielleicht mal nach EMV (elektro-magnetische verträglichkeit) googeln. ein gutes emv konzept sollte von anfang an mit in das funktionskonzept einfliessen.
zb messdatenleitungen separat verlegen.

abschirmung ist auch von "innen" nach "aussen" sinnvoll. oberstes gebot ist nämlich, störquellen zu eleminieren.

immer nach dem motto: leben und leben lassen.  ;)

Zitat von: Beta-User am 10 Mai 2020, 18:17:53
... Habe auch so einen dusseligen (Wasserzähler) mit den kleinstmöglichen roten Zeigerchen, bei dem diverse Varianten von Näherungssensoren und modifizierte TCRT500-Schaltungen nicht wollten  :( )

Kurze Antwort: Ich hab auch einen Wasserzähler mit rotem Rad, mit immerhin etwas Metall drin, allerdings ging es nicht mit einem 8 mm induktiven Näherungssensor, aber mit einem 12 mm Sensor, der eine größere Distanz bzw. höhere Empfindlichkeit hat.

Viele​ Grüße​ Gisbert​

Zitat von: Beta-User am 10 Mai 2020, 18:17:53
(@RichardCZ: Falls es zu OT wird hier, darfst du das gerne äußern!)

Das ist für mich alles noch On-Topic.  ;)

Diese 37er/45er Sensorsets habe ich auch schon gesehen und wollte/werde vielleicht auch mal was bestellen - aber bis das im Juni angekommen wäre ... da wollte ich jetzt was haben.
Aber wenn sich die RobotDyne Black Pills bewähren, dann kaufe ich da mal einen Schwall von (also schon so 50+) unseren kleinen gelben Freunden.

Zitat von: RichardCZ am 10 Mai 2020, 10:25:47
...Moeller hat hier ein paar interessante Zahlen zu verschiedenen Bussystemen (einschl. Übertragungskapazität/Länge) und gibt Empfehlungen zu Kabeln ab...

Intressanter Link. Danke Dir. Die Frage nach dem Kabel quält mich schon eine Weile.
Dass die Impedanz 120Ohm sein müsste, hatte ich mir anhand der nötigen Abschlusswiderstände zusammengereimt (konkretes wie im Möller-PDF bisher nicht gefunden).
Nur, welches (normal kaufbare) Kabel bringt dies mit? Welchen Leitungsaufbau sollten man nehmen, einfach verdrillt, Sternvierer oder oder?

Ich dachte an billiges J-Y(ST)Y. Leider finde ich keine Datenblätter. Hatte was gelesen von 70 - 130Ohm Impedanz, je nach Anzahl Leiter. Aber an sich müsste es doch OK sein: zwei Adern vedrillt, geschirmt, man kann bei 2x2x0,6 GND und 12V/5V f. die Nodes mitführen (wg. zentralem Netzteil) und dünn genug, um neben vorhandenen Kabeln ins Leerrohr gezogen zu werden.

Allerdings ist solch Kabel oft verpöhnt (meist im Telekomunikationsbereich, weil dort Impedanz von 100Ohm und Sternvierer vonnöten; z.B. https://telekomhilft.telekom.de/t5/Telefonie-Internet/Das-richtige-Kabel-zwischen-APL-und-TAE-Dose/ta-p/3499089 (https://telekomhilft.telekom.de/t5/Telefonie-Internet/Das-richtige-Kabel-zwischen-APL-und-TAE-Dose/ta-p/3499089) ).

Öfter habe ich auch gelesen, dass einige gleich CAT7 Verlegekabel nehmen - egal wofür - wäre mit etwas overkill. Manchmal wird Schirmung empfohlen, dann wieder nicht oder wenn, dann nur fliegend - also weder vorn noch hinten den Schirm angeschlossen  :o

Herrje, Fragen über Fragen. Was wäre best practice bzw. was wären gute Erfahrungswerte?

Vielen Dank und beste Grüße
rob

Zitat von: rob am 11 Mai 2020, 08:45:23
Intressanter Link. Danke Dir. Die Frage nach dem Kabel quält mich schon eine Weile.
Dass die Impedanz 120Ohm sein müsste, hatte ich mir anhand der nötigen Abschlusswiderstände zusammengereimt (konkretes wie im Möller-PDF bisher nicht gefunden).
Nur, welches (normal kaufbare) Kabel bringt dies mit? Welchen Leitungsaufbau sollten man nehmen, einfach verdrillt, Sternvierer oder oder?

Ich dachte an billiges J-Y(ST)Y. Leider finde ich keine Datenblätter.
...
Öfter habe ich auch gelesen, dass einige gleich CAT7 Verlegekabel nehmen - egal wofür - wäre mit etwas overkill. Manchmal wird Schirmung empfohlen, dann wieder nicht oder wenn, dann nur fliegend - also weder vorn noch hinten den Schirm angeschlossen  :o

Herrje, Fragen über Fragen. Was wäre best practice bzw. was wären gute Erfahrungswerte?

Zu best practice hier was mich betrifft: Keine Ahnung - zumindest noch nicht.

Datenblätter zu Kabeln habe ich so auch nicht, aber ich vertraue da darauf wenn ein Hersteller sagt "Dat is jut für RS485".
Weil wenn nicht, können die dann jemanden vorbeischicken, der das wieder aus der Wand rupft. (Und gleich das Haus mitsaniert)  ;)

https://www.lappkabel.de/produkte/online-kataloge-shop.html?q=RS485

Hinsichtlich Cat(5|7) Kabeln habe ich eher gelesen, dass die ziemlich ungeeignet sind für RS485/CAN Verkabelung, alleine schon wegen
Topologie. Ich hatte auch mit dem Gedanken gespielt einfach die Cat-Verkabelung etwas dicker ausfallen zu lassen und dann zu verwenden.

Aber nö - ist wohl nicht so das Wahre.

Hinsichtlich Stromversorgung hatte ich auch eine Weile über ein "Power-over-RS485" sinniert. Naja, eigentlich 4 Adern, aber bei mir liegt eine Luxus-Situation im Haus vor, Unabhängiger "48V DC Stromkreis" (genauer ~50-55) und den werde ich mittels LM2576HV für dieses Nervensystem mitbenutzen. Der Strom ist auch nach einem EMP da.  Ok - wahrscheinlich nur der. :)

Und wenn man spezifisch nach CAN Kabeln sucht, dann ist der Preis mal eben beim Doppelten.

https://www.lappkabel.de/produkte/online-kataloge-shop/datenuebertragungssysteme/datenleitungen-niederfrequenz/kapazitaetsarm/unitronic-li2ycy-tp.html?q=CAN&Aderzahl[0]=2

Ich tendiere in diesem Fall eher zum Nichtsparen, aber alles hat seine Grenzen und mehr als 3€/m sollten es auch nicht werden, sonst kann ich ja gleich die Leitung aus Blue Pills aufbauen.

Zitat von: rob am 11 Mai 2020, 08:45:23
Öfter habe ich auch gelesen, dass einige gleich CAT7 Verlegekabel nehmen - egal wofür - wäre mit etwas overkill. Manchmal wird Schirmung empfohlen, dann wieder nicht oder wenn, dann nur fliegend - also weder vorn noch hinten den Schirm angeschlossen  :o

Ich lese mit, weil wir vermutlich in nächster Zeit ein Haus kaufen das kernsaniert werden soll, dabei möchte ich auch einen Bus legen und CAN/RS485 ist eine Option (neben HmIP-W und KNX). Warum hältst du CAT7-VK für Overkill?

@RichardCZ:  :o 50+? Willst du den Tester machen für "gehen mehr als 32 CAN-Transceiver an einem Bus@MySensors?" (und warum dann nicht gleich 128+?!? :P ). Oder renovierst du grade ein Schloss und willst Technik verlegen, die auch noch für die Ur-Urenkel paßt?

Den RFID-Reader-Sketch habe ich mal angehängt, ist vermutlich nicht in meinem Repo, wie gesagt: No Guarantee, den habe ich derzeit nicht im Einsatz.

Was Kabel angeht, habe ich ein ziemliches Sammelsurium im Einsatz: Vom Server in den Keller ist es CAT6 oder 7 (also ein verdrilltes Paar daraus bzw. gelegentlich 2 für den Hin- und Rückweg, meistens sind dann die 12V in einem weiteren Paar), und im Keller größtenteils auch, der Rest sind handelsübliche 4-adrige Telefonkabel, die Kabelstärke paßt in etwa zusammen. Das ist praktisch an allen Nodes mit kleinen Wago-Steckverbindern zusammengestückelt. Meine Skepsis gg. höheren Datenraten hat daher auch was mit der konkreten Verkabelung zu tun ::) ...

@rob: Im Starter-Guide ist bei RS485 irgendwo ein Link zu einem Berechnungstool, mit dem man bei verschiedenen Kabelstärken auch die Abschlusswiderstände usw. berechnen kann. Das scheint halbwegs valide zu sein, was da rauskommt...

@Gisbert: Bis 8mm hatte ich ausgetestet (12V-Variante, es gibt hier ja eine zentrale Versorgung ;) ); meiner ist ein Zenner, der ähnlich aussieht wie der von hier (https://www.mysensors.org/build/pulse_water). Das ist eine der Sachen, bei der die Bebilderung auf der MySensors-Seite übrigens irreführend ist, siehe dazu auch die mMn. nicht ganz unberechtigte "Generalkritik" an der (Aktualität der) Einführungsliteratur zu MySensors hier (https://forum.mysensors.org/topic/11145/started-with-mysensors-and-about-to-give-up-some-feedback) (u.a. aus diesem Grund wäre es super, wenn PJON ans laufen käme. Dann braucht man zum Einsteigen nur noch zwei Arduinos, und kann sich mit den sehr viel komplzierten Fragen betr. der elektrischen Auslegung von RFM-based Nodes dann beschäftigen, wenn man das Grundprinzip verstanden hat). "Grundsätzlich" scheint mein angehängter "puls-Laser"-Sketch zu funktionieren, ich bin aus diversen Gründen nur noch nicht dazu gekommen, den sauber auszurichten und zu kalibrieren. Aber wenn du denselben Zähler, ein Bildchen vom Aufbau und die genaue Type von dem Näherungssensor hättest, wäre das evtl. auch eine Alternative, die Schaltung vom Näherungssensor hätte ich sonst eben für's Garagentor verwendet...

@andies: RFM96 hätte dir übrigens mit großer Sicherheit das Einarbeiten in die Antennentechnik "erspart" (da war doch was mit einem Wasserzähler weit entfernt vom Haus, der "unbedingt" in MomeMatic-BidCoS sein "mußte" ;) ...). Aber man weiß ja nie, für was erweiterte Kenntnisse gut sind ;D .
(Falls jemand in einem größeren Mehrparteien-Haus wohnt und was für den Keller sucht, das so weit funkt: here you are, take RFM96-LoRa... Aber schon mit einem "guten nRF24L+" (die ungeschirmte 1.100m-Variante hatte ich hier mal auf Reichweiten getestet. Ich kam auf  jenseits 100m in einem lose überbauten Wohngebiet, also im Freien ohne ganz direkte Sichtverbindung, das GW innerhalb meiner Hütte. Mit der geschirmten 2.300m (?)-Variante geht da bestimmt noch mehr.)

"Damals" hatte ich bei meinen Eltern CAT5e verlegt und für fast alles genommen. Außer wenn wirklich "Strom" (Auch Niederspannung) transportiert werden mußte. Dafür sind Netzwerkkabel wirklich sehr ungeeignet. Ist zwar teurer als "Klingeldraht", aber man spart sich Kabelziehen ...

Bevor ich jetzt einen Hinweis wegen PoE bekomme, man überlege sich, was dort für "Klimmzüge" gemacht werden, um die "Leistung" durchs Netzwerkkabel zu bekommen.

Nachtrag noch zu meinem Setup:
Die längste Kabelstrecke dürfte zwischen Server und Keller sein. Das Netzteil hängt aber im Keller, das hat mit der Strecke "nach oben" nix zu schaffen.

Meine Versuche mit 5V waren - vermutlich wg. der Leistungsverluste in den Leitungen - nicht sehr befriedigend, daher jetzt (wieder) die 12V-Variante. Da die Nodes selbst kaum Strom brauchen (schwankt etwas, aber insgesamt ~3W für den ganzen Aufbau, wie gesagt: echte Verbraucher sind galvanisch getrennt), dürfte die übertragene Leistung nicht das große Problem darstellen. Hat man kurzzeitige Verbrauchsspitzen, kann man ja vor Ort puffern, hin und wieder ein Kondensator ist sowieso vermutlich eine gute Idee.

Was die Stromversorgung angeht, kann man die ja durchaus "im Stern" machen, also anders als die eigentliche Busverkabelung. (Oder bin ich zu naiv, was das angeht?)

@Christoph Morrison: Wenn du eh' HM-IP im Einsatz hast, wäre vermutlich die HM-Wired-Variante für deinen Anwendungsfall auch eine Option. eQ-3 arbeitet afaik mit 24V und einer Art Widerstandsnetzwerk.

@all: Zum Thema  Busauslegung gab es auch mal einen "Spezialthread"; vielleicht wäre es günstiger, diesen Teil der Diskussion dort weiterzuführen (die Erlaubnis des dortigen TE ist hiermit erteilt...), da ist nämlich auch schon manches Theorieschnippselchen zu finden. (Mir ist das aber im Grunde egal, wo).

Zitat von: Beta-User am 11 Mai 2020, 09:26:42
@RichardCZ:  :o 50+? Willst du den Tester machen für "gehen mehr als 32 CAN-Transceiver an einem Bus@MySensors?" (und warum dann nicht gleich 128+?!? :P ). Oder renovierst du grade ein Schloss und willst Technik verlegen, die auch noch für die Ur-Urenkel paßt?

Schloss ist es nicht gerade, aber bei der letzten Zählung brauche ich mindestens 25, wenn ich "Ein Kästchen pro 'Zimmer'" haben will. Wobei "Zimmer" ein abstraktes Konzept ist. Garage, Dachboden, Garten, 30m³ Regenwasser-Zisterne tief im Erdmantel,.. sind auch 'Zimmer'.

Gehe ich von der MySensors Baumtopologie aus (https://www.mysensors.org/about/network), dann werde ich ein wenig aggregations-Overhead brauchen (Repeater Nodes). Vermutlich bin ich dann froh wenn ich unter 32 bleibe. Wobei mir immer noch nicht ganz klar ist, wie so ein Stern zu einem parallel Bussystem zusammenpasst. Für mich sieht das so aus, als wären die Äste nach den Repeater Nodes eigenständige RS485 Busse.

(Dann wird sicher was kaputt ankommen, bzw. kaputt gehen und irgendwas braucht man auch auf Vorrat.)

Das Problem bei "Stromtransport" ist immer der Querschnitt. 1W bei 10V ist eben 0.1A. Dagegen bei "hypotetischen" 1V gleich 1A und damit Deutlich Wichtiger. Auch ist, vereinfacht gesagt, der "Widerstand" der Leitung bei höheren Spannungen geringer als bei kleinen.

Genau gelernt habe ich es im Studium ... aber mittlerweile als Unwichtiges Wissen aussortiert, außer obiger "Faustformel"

Edit:
@RichardCZ
Kannst Du den Baum ansonsten nicht in mehrere Aufteilen? Hat den Vorteil, das bei Ausfall eines Baumes die anderen weiterlaufen ... bei dem Nachteil, das DU mehr USB-Bussystem-Konverter brauchst. Aber sooo teuer sind die auch nicht.

Zitat von: Christoph Morrison am 11 Mai 2020, 09:20:15
Ich lese mit, weil wir vermutlich in nächster Zeit ein Haus kaufen das kernsaniert werden soll...

Das habe ich in 2014 durchgemacht. Leider konnte ich bautechnisch keine strickte Sternverteilung jeder einzelnen Dose/ Lichtanschlussstelle zum Zentralverteiler durchführen (zuviel schlitzen ist wohl schlecht für die Statik ;) )

Zitat von: Christoph Morrison am 11 Mai 2020, 09:20:15
Warum hältst du CAT7-VK für Overkill?

Nicht pauschal. Nur bezogen auf diesen Zweck. Tatsächlich habe ich damals überall dort CAT7 verlegt, wo ich auch Netzwerk machen wollte.

Jetzt geht es mir z.B. darum die Garagentorsteuerung (ConfigFirmata@Esp8266 funktioniert super, bis auf das schlechte Wifi) durch Kabellösung abzulösen. Dafür benötige ich max. 4 Adern und simplen Schirm. Lass Dich von mir also nicht irritieren :)

Viele Grüße
rob

OT: Ich fand u.a. das Buch "Heimautomation mit KNX, DALI, 1-Wire und Co." (ISBN-10: 383626613X) hilfreich, weil viel auf Grundausstattung+Planung eingegangen wird. Der Rest ist zwar stark auf KNX ausgelegt und m.E. viel nur im Neubau möglich, aber trotzdem half es mir.

Zitat von: Wernieman am 11 Mai 2020, 09:56:46
@RichardCZ
Kannst Du den Baum ansonsten nicht in mehrere Aufteilen? Hat den Vorteil, das bei Ausfall eines Baumes die anderen weiterlaufen ... bei dem Nachteil, das DU mehr USB-Bussystem-Konverter brauchst. Aber sooo teuer sind die auch nicht.

Ich bin eher am Kopfkratzen was die Repeater Nodes anbelangt. Das scheint für kabellos konzipiert zu sein, aber wenn man es "richtig" macht und das GW ist physisch zentral im Haus gelegen, ist das für einen Bus ziemlich schlecht, weil man dann die Kabel "am GW vorbei" von einem Ende des Hauses zum anderen ziehen müsste und dann wieder zum GW zurück.

Aber Du hast recht, vermutlich kann ich Repeater knicken und ein Multi-GW realisieren. Da hätte ich mir dennoch gewünscht, dass man z.B. eine Node mit mehreren RS485/CAN Ports ausstatten kann.

Meine Frage war einfach allgemein. Speziell "RS485/CAN" kenne ich mich nicht aus ...

ich z.B. würde bei I2C einfach viele esp8266 nehmen und damit viele Kleine i2c-Busse nehmen. Andere dagegen legen sich einen riesen Bus ins Haus. Hatt alles seine Vor/Nachteile.

Für mich blöde: esp8266 hat WLAN .... und nicht Kabel. Schade das es keine einfache alternative "Kabellösung" dafür gibt ... andererseits kann ich in meiner aktuellen Mietwohnung schlecht Kabel legen ;o)

Zitat von: Beta-User am 11 Mai 2020, 09:26:42
Den RFID-Reader-Sketch habe ich mal angehängt, ist vermutlich nicht in meinem Repo, wie gesagt: No Guarantee, den habe ich derzeit nicht im Einsatz.

Mit dem Wiegand Dual-Reader 7304D2 (z.B. https://www.ebay.de/itm/Dual-Frequency-RFID-Reader-Wireless-Module-13-56MHz-125KHz-ISO14443A-EM4100/264698370838 (https://www.ebay.de/itm/Dual-Frequency-RFID-Reader-Wireless-Module-13-56MHz-125KHz-ISO14443A-EM4100/264698370838)) habe ich seit >1 Jahr sehr gute Erfahrungen gemacht (können 125KHz + 13,56MHz, was ich beides auch brauche).
Hängt noch an einem EspEasy@Wemos, aber für MySensors gibt es auch schon ein Wiegand-Beispiel https://forum.mysensors.org/topic/5248/rfid-card-reader-wiegand (https://forum.mysensors.org/topic/5248/rfid-card-reader-wiegand), womit ich mich befassen möchte.

Viele Grüße
rob

Zur Topologie @RS485: Das ist eine strikt lineare Bus-Topologie, die man da planen sollte. Das ganze ist eher zu vergleichen mit dem 1-Wire-System (da hat pah viele wertvolle Hinweise ins Wiki gepackt).

Deswegen hatte ich hier auch geschrieben "Hin- und Rückweg" iVm. dem Hinweis auf ein separates Paar Adern. Repeater braucht man nur bei Funk und nur dann, wenn die Reichweite nicht ausreichend ist (oder man sniffen will). Bei RS485 erreicht aber jede Node das GW...

---

Zu meinem MFCR522-Sketch: Der funktionierte at the time of writing 8) .
Ich hatte nur ursprünglich mal vor, den Leser (versorgt über Wechselspannung) in meiner Türsprechanlage zu verstecken und eine "öffne mit Handy"-Option damit einzubauen. Zwischenzeitlich habe ich das Problem aber anders gelöst und den Sketch nur mal für einen anderen User hier zusammengebaut, der RS485 nutzt, aber einen anderen Leser (I2C) und Probleme damit hatte, die Wandlung von String nach Char zu machen... Der Teil klappte jedenfalls, danach landete das Ding wieder in der "Grabbelkiste".

---

Damit sind wir bei zwei anderen Themen:

Wechselspannung (12V?) wäre ggf. eine Variante, die Leitungsverluste zu minimieren. Das erfordert dann aber wirklich wieder weitere Bauteile, um den Arduino damit zu versorgen... (ich habe zwar (Grund: s.o.) ein paar Module aus China rumliegen, kann aber nicht sagen, ob das ggf. funktionieren würde.)

I2C:ALLES, wofür sich eine funktionierende Arduino-lib findet, bekommt man mit MySensors in ein FHEM-Reading!
Da man "sowieso" den Code selbst schreiben muß, sind auch mit einem simplen ATMega32 zwei (oder mehr) gleiche Typen möglich, wenn man die Adressen umschalten kann. Und für die meisten Typen gibt es auch Standard-Formate, letztlich ist es egal, WIE eine Temperatur jetzt gemessen wird...

(Da fällt mir der PCF8583 (https://www.nxp.com/docs/en/data-sheet/PCF8583.pdf) wieder ein. Ein I2C-Uhren-Bausteinchen, den ich irgendwann mal ::) in meine Super-Duper-Wetterstation mit Windwarner einbauen wollte. Der kann "leise" Zählen und den Arduino dann aufwecken, wenn eine bestimmte Zahl Counts überschritten ist). Na jedenfalls, falls jemand noch einen "schwierigen Baustein" (stimmt vermutlich nicht) für seine China-Bestellung sucht: den habe ich vorhin vergessen...).

Und wer I2C-Bausteine nutzen will, braucht meistens 3.3V. Das ist v.a. dann "gut", wenn man die RFM-Varianten für Funk im Einsatz hat! Damit wird dann das Platinenlayout wieder deutlich einfacher, man muß nur ggf. die Frequenz des ATMega runter nehmen... (@Wernieman: Es gibt afaik. ein paar ziemlich ausgereifte Platinen dafür; RFM ist typischerweise 868MHz oder 433MHz...)

@Beta-User: zum induktiven Näherungssensor LJ18A-A3-8-Z/BY am Wasserzähler (Foto im Link), der bei mir funktioniert, siehe diesen (https://forum.fhem.de/index.php/topic,110021.0.html) Thread.

Ah ok, den Thread kannte ich, es fehlte mir nur das Bild dazu (ist im ersten Beitrag hier: https://forum.fhem.de/index.php/topic,110021.msg1040217.html#msg1040217 (https://forum.fhem.de/index.php/topic,110021.msg1040217.html#msg1040217)).
Meiner ist ein "MNK" (S. 6 hier (https://www.zenner.de/files/content/AAA_Dokumente/Produkte/Hauswasserzaehler/MNK/KT_HWZ_DE_110804_W.pdf)) ohne "Fernausleseoption"). Ich vermute zwar, dass in der Mitte trotzdem irgendwas magnetisches verbaut ist (wie bei dem "MNK-N") anzunehmen, aber "auf Risiko" hole ich mir im Moment nicht "noch einen" Sensor aus China, sondern werde erst mal meinen "Pulser" versuchen richtig auszurichten. Mal schauen, ob ich schneller bin wie der lokale Wasserversorger - der muss kommendes Jahr sowieso wieder getauscht werden (von daher ist zum "veralgen" eh' nicht mehr so viel Zeit, falls ich das mit dem Pulsen doch sein lassen müßte)...

Für die Zähler mit dem relativ großen roten Halbreis würde mMn. auch ein (ggf. auf grünes Licht modifizierter) TCRT5000 gehen, bei Stall.biz gibt's dafür eine schöne Bauanleitung. Ein "normaler TCRT5000" (in Fertigmodulform) werkelt hier auch ohne erkennbare Probleme beim Gaszähler (Pipersberg Balgenzähler mit reflektierender 6).

EDIT sagt:

Zitat von: Gisbert am 11 Mai 2020, 14:01:53
LJ18A-A3-8-Z/BY

Der hat 8mm, nicht 12, oder? Die 8mm-Variante habe ich nämlich (nach einer netten Diskussion mit Schotty zu diesem Thema) extra auch ausgetestet. Der wollte nichts erkennen (dahinter war eine Optokopplerschaltung; der Teil funktionierte...).

Hallo Beta-User,
ich habe genau den hier (https://www.aliexpress.com/item/32758065433.html?spm=a2g0s.9042311.0.0.79134c4dwcrbSd), Durchmesser 16.5mm und Detection distance: 8mm, vielleicht liegt hier die Dieskrepanz. Es gibt, glaube ich, noch fettere Teile, deren Detektionsdistanz noch größer ist, vorausgesetzt, es gibt etwas Metallisches, was sich detektieren lässt.
Viele Grüße Gisbert

Na ja, zusammengefaßt zu dem [OT-] Thema Wasserzähler: nix genaues weiß man nicht, die Zähler sind auch definitiv nicht dieselben. Was auf dem Bild mit dem "-N" gut zu erkennen ist: Zenner selbst scheint eher einen Reed-Kontakt einzusetzen, und den dann ziemlich genau in der Mitte des Zählers zu positionieren. Von daher bin ich eher skeptisch, ob der Magnet/das Metallplättchen da wirklich auch bei der "Nicht-N"-Variante drin ist. Irgendwo gab es auch Zeichnungen, wie mein Zähler intern aussieht, und da könnte es schon sein, dass das als Zusatzbauteil ausgelegt ist, das man bei Nichtbedarf weglässt... Falls es weiter regnet, finde ich vielleicht Zeit, die Laser-Variante mal wirklich zu fixieren (das Problem ist: Man muß den Laser in einem gewissen Abstand über dem Zähler fixieren, und dann das reflektierte Restlicht detektieren. Die simpelste Variante wäre ein Kunststoffrohr drüberzustülpen (auch wegen anderen Lichteinflüssen) und beide Teile daran innen festzuzurren. Aber da war irgendwann die Geduld aus und kein passendes Stück Rohr zur Hand, und auch keine große Rohrschelle, mit der ein Winkel über dem Zähler zu justieren gewesen wäre... Muß aber wohl eh' demnächst mal wieder mit die Maske überziehen und den Baumarkt überfallen ::) .)

---

Back in topic:
Hier berichtet jemand, dass er aktuell Probleme hätte mit der Blue Pill: https://forum.mysensors.org/topic/11151/how-to-compile-mysensors-on-platformio-for-blue-pill. Das sieht mir aber nicht nach Problemen beim Flashen aus, sondern eher mit dem STM32-Core (ich bin mir aber ziemlich sicher, dass ich im Keller ein RFM69-Gateway auf Maple-Basis liegen habe, das mit älteren libs compiliert wurde und funktioniert.

---

Was das Thema Sternverkabelung angeht: PJON schein in die Richtung toleranter zu sein (war jedenfalls auf den neulich hier verlinkten Seiten zu lesen, wenn auch nicht im Zusammenhang mit MySensors).

Ja wenn schon, dann programmieren wir Arduinos objektorientiert.  ;)

https://gl.petatech.eu/root/mysensors-exp/-/commit/7c043cdc46e1cd47fd09f52b6e6ffeb42f65820d

Zitat von: RichardCZ am 11 Mai 2020, 22:24:19
Ja wenn schon, dann programmieren wir Arduinos objektorientiert.  ;)

Aber gerne doch! (Meine Sketches würden heute evtl. ( ::) ) auch anders aussehen).

Anmerkungen:
- Warum dann kein #include samt entsprechendem header+cpp?
- Ohne das näher geprüft zu haben müßte das hier den code weiter vereinfachen helfen, oder? https://playground.arduino.cc/Code/Timer/

---

Da wir irgendwie auch noch den Grabbelkisten-Anteil in dem Thread haben, noch ein paar "Schätzchen":

Kennst du vermutlich (klang danach, als wären die bestellt) - kapazitative Touch-Taster (https://www.ebay.de/itm/10x-TTP223-Kapazitiver-Touch-Sensor-Capacitive-Schalter-Arduino-Raspberry-Pi-TOP/333064137392?_trkparms=ispr%3D1&hash=item4d8c2b6ab0:g:R5AAAOSwbRNcXumN&enc=AQAEAAACcIQvEcHUrT7nmUC3yY5qbPyaBN1nJEDYW8MyypsJPgXKjzb4uel3XQiGEzY4CITgmopFfFBh6NRTarAjlLFvOkjmesv1GE5QYn7KI%2Ff%2BA2jwSAh9P7MQhW%2FU6ocD55TURRL%2Bdj%2B6AFclQhIFUUJ9brgfU8Lrf731H%2BIZXXkvMgQ0Ve28OTYar9%2FLd%2FrI8keKghsh02vG%2BFG2MBJ8HTRTNnzxF5liSXATUsbOsdWnehTM1cGq5C7BFTuXwaln0yOtvQXcDkCXSHsuzMLothAoabt9BNFjJODBU4HcQKGSwhpzg20Y0xGXhD6fhO%2BP%2BgW0Ik4KjJwR8PIS1FhCKKOT3fSncZ7WjnxObfUvfbHha7j9sjxYELpIAPHy%2BK%2FNhYFnOnJg2UOjq8kOCj29VM5b34bVypVCB9QiFNRP3DJnb96zrptJkh9x8PjPrXuxmw9z3pLvxqTAF3eB9cahgyBuiXsm0hBHSxTskvRoFUDP%2F0PHaQn3Bu5mAur9iZTBGqlRqe7G40yuxgQ%2Fjcqz7v80L2r7grDgzGA1IUdiruTMXCKEN%2B7K2hsljgTBIyzc1U4QELwYQHujhQTLpX0vYizw%2B6JWCEROgE%2F19qbDxS0r0dzemLAcp7%2FFa4cWCQe71sdoOwz8A6Ed95RfUAPCz9FIGqaWT1V39YcuXD9hZe5iN6as%2FxIqI3dYnC65rbhsaSnmpOhHsZ3Q9XeC1erhuryXNgHmotKsc%2FadsDg5rCU2jipmfmdOtdDGMJn1J%2FnFy%2FIWcSk6lXcVpcrRJ2ejQbmlrq2C%2BTPAfejy9oTM9eUMxjJ0aJk%2FfzPjNdynlFVTdgyOTA%3D%3D&checksum=33306413739237b4ec665cac4d8ea322cab13d366249). Sind super, wenn man im Außenbereich versteckte Schaltmöglichkeiten braucht. Steckt z.B. neben meiner Regenwasserpumpe in einer spritzwassergeschützten Aufputzdose...

Für Wassertanks auch nett (auch wenn das Kabel länger sein dürfte): Schwimmerschalter (https://www.ebay.de/itm/Water-Liquid-Level-Sensor-Liquid-Plastic-Ball-Float-Switch-Fur-Arduino/152850786324?_trkparms=aid%3D1110006%26algo%3DHOMESPLICE.SIM%26ao%3D1%26asc%3D225116%26meid%3De12de2fbba71429a8353b2a4b81992b3%26pid%3D100005%26rk%3D3%26rkt%3D12%26mehot%3Dco%26sd%3D272579131278%26itm%3D152850786324%26pmt%3D1%26noa%3D0%26pg%3D2047675%26algv%3DSimplAMLv5PairwiseWeb%26brand%3DMarkenlos&_trksid=p2047675.c100005.m1851). Gestern noch in einer "extended version (https://www.ebay.de/itm/Edelstahl-Schwimmerschalter-Niveauschalter-Wasser-Fullstandsensor-CN/293564114198?_trkparms=aid%3D1110006%26algo%3DHOMESPLICE.SIM%26ao%3D1%26asc%3D225116%26meid%3D3c1025e4461947ed83aa236122f74f4c%26pid%3D100005%26rk%3D4%26rkt%3D12%26mehot%3Dco%26sd%3D252712289600%26itm%3D293564114198%26pmt%3D1%26noa%3D0%26pg%3D2047675%26algv%3DSimplAMLv5PairwiseWeb&_trksid=p2047675.c100005.m1851)" gefunden, hat soweit erkennbar zwei Schaltpunkte mit ~10+cm Abstand - sehr nett, wenn man einen Wasserstand in einer "Gießkannentonne" innerhalb eines bestimmten Bereichs halten will.

Zitat von: Beta-User am 12 Mai 2020, 09:52:57
Aber gerne doch! (Meine Sketches würden heute evtl. ( ::) ) auch anders aussehen).

Anmerkungen:
- Warum dann kein #include samt entsprechendem header+cpp?
- Ohne das näher geprüft zu haben müßte das hier den code weiter vereinfachen helfen, oder? https://playground.arduino.cc/Code/Timer/

- Weil spät Abend.
- ja, als unbedarfter Neuling erfindet man das Rad schonmal neu. Das kann man ab und zu bei Projekten beobachten.  ;)

Ich muss bei dem Arduino Zeug erstmal "ein Gefühl für" bekommen. Hardware Timer wollte ich explizit nicht benutzen um später ggf. nicht irgendwelchen libs in die Quere zu kommen. Naja und dann fehlt mir natürlich noch das Bibliothekswissen. Muss mich mal rumtreiben um zu sehen was es so an fertigen Rädern schon gibt.

Zitat
Da wir irgendwie auch noch den Grabbelkisten-Anteil in dem Thread haben, noch ein paar "Schätzchen":
Kennst du vermutlich (klang danach, als wären die bestellt)

kommt morgen: https://www.laskarduino.cz/robotdyn-kapacitni-dotykovy-senzor-ttp223b/

Die Timer-Geschichte müßte millis()-basiert sein und von daher nicht an einer konkreten Hardware abhängig sein: https://github.com/JChristensen/Timer/blob/master/Timer.cpp#L45. Kann aber sein, dass ich mich täusche, meine C-"Kenntnisse" sind eher noch schlechter wie die in Perl ;D .

Zitat von: Beta-User am 12 Mai 2020, 11:03:03
Die Timer-Geschichte müßte millis()-basiert sein und von daher nicht an einer konkreten Hardware abhängig sein: https://github.com/JChristensen/Timer/blob/master/Timer.cpp#L45.

Ja klar. Er macht's "genau so" wie ich. Bzw. ich wie er.  :) Ich sage ja - Mangel an neuen Rädern gibt's nicht.

PS: Es wird echt immer schlimmer...

Schlimmer? You ain't seen nothing yet ;D , zumindest nicht meine "Kunstwerke"... (Nein, ich hol' die nicht aus ihren Dosen ::) !)

Das sieht jetzt schon irgendwie nach RS485 aus :) . Die Kabelführung "raus aus dem Bild" bzw. zum vorderen Nano hin gibt allerdings Rätsel auf? Sind da noch mehr Nanos? Und Verbindungen DE-RE sehe ich auch keine, habe aber vermutlich mal wieder was übersehen.

Einen Screenshot von HoBo mit laufendem "on-for-timer" für das Relay hast du nicht zufällig schon parat? (Schon klar, zu früh: du mußt erst noch kurz die MySensors-libs renovieren :P .)

Flenn

Ich bin unfähig und brauche Hilfe. Gateway aufsetzen ist scheinbar (nach allem was ich so interpretiere) kein Problem, aber irgendwie fehlt mir wohl das tiefere Verständnis wie ich da einen "stinknormalen" Node dahinterhänge.

Gateway hängt am USB am Rechner
Gateway und "Node dahinter" sind via RS485 verbunden.

Log sagt das hier. Das sieht aus wie "Gateway initialisiert, ruft aber in den finstren Wald hinein ohne Echo"

0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RSNGA---,FQ=16,REL=255,VER=2.3.2
0;255;3;0;9;5 MCO:BGN:BFR
0;255;3;0;9;8 TSM:INIT
0;255;3;0;9;10 TSF:WUR:MS=0
0;255;3;0;9;12 TSM:INIT:TSP OK
0;255;3;0;9;15 TSM:INIT:GW MODE
0;255;3;0;9;18 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;21 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.3.2
0;255;3;0;11;Relay
0;255;3;0;12;1.0
0;1;0;0;3;
0;255;3;0;9;29 MCO:BGN:STP
0;255;3;0;9;36 MCO:BGN:INIT OK,TSP=1
0;255;3;0;9;39 TSM:READY:NWD REQ
0;255;3;0;9;59 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

Warum bekomme ich immer die kaputten?

Nachtrag:

Eine Ewigkeit später ist noch das hier aufgetaucht:

0;255;3;0;9;900011 TSF:SAN:OK

0   255   INTERNAL   false   I_LOG_MESSAGE   900011 TSF:SAN:OK   Sanity check passed

(ich lasse mir hier helfen: https://www.mysensors.org/build/parser)

Das sieht ja alles im Prinzip ermunternd aus, aber irgendwie besteht mein Mordsnetzwerk nur aus einem Node - dem Gateway.

NodeID ist bei der "echten" Node vergeben? Via Sketch?

EDIT: So ganz schlau werde ich aus der Schilderung nicht. Daher nochmal die "Minimalbedingungen":
1. Hinter dem Gateway muß ein Controller sitzen (z.B. FHEM). Kommt von dort auf bestimmte Anfragen keine Rückmeldung, startet keine der Nodes normal durch, sondern versucht bis in alle Ewigkeit, erst mal Verbindung mit dem Controller aufzunehmen. Wenn man das anders haben will, muß man das aktiv (im Sketch) unterbinden (das habe ich bei allen meinen Nodes, z.B. "#define MY_TRANSPORT_WAIT_READY_MS 20000" für 20 Sek.).
2. Bei RS485 klappt die automatische Vergabe von ID's nicht (es scheint bei RS485 keine vorgegebene Hardwareadresse zu geben, an die man eine entsprechende Nachricht zurücksenden könnte). Daher muß man die im Sketch (außer bei Gateways) vorgeben.

Also:

Im Sketch habe ich #define MY_ID 10.
Gateway bekommt wohl immer ID 0

Das mit dem Controller ist für mich ein Novum. Ich hätte mir das jetzt eher so vorgestellt/gewünscht, dass ich hinters Gateway ein einfaches Minicom klemme und beobachte wie da die Daten eintrudeln. Übrigens, im Sketch (der Node 10) war noch die SLEEP_TIME auf 120s gestellt, das habe ich jetzt auf 1s runter.

unsigned long SLEEP_TIME = 1000;

Aber nüscht tut sich. Nur die rote LED (also die für Error, ich habe rot, gelb, grün verbaut) der Node blinkt ab und zu.

// Enable debug prints to serial monitor
#define MY_DEBUG

Habe ich auf dem GW aktiviert.
PS: Mehr Spielsachen sind da - u.a. die Black Pills. Hoffentlich funktioniert dann auch mal was davon.

Wenn ohne Controller, dann mit
#define MY_TRANSPORT_WAIT_READY_MS 200
Und mit sleep würde ich bei zentral versorgtem RS485 gar nicht anfangen, sondern alles als non-blocking loop auslegen. SLEEP_TIME hat jedenfalls bei den Standardsketchen mit der Anfrage nach einer Rückmeldung vom Controler nichts zu tun.

(Und meine Sichtweise auf "Hoffentlich funktioniert dann auch mal was davon": es tut alles so, wie man es erwarten würde! Die Node versucht alle paar Minuten (?, jedenfalls erst in kurzen Zyklen, dann immer länger werdend, bis irgendwann mal die Obergrenze erreicht ist) mal wieder, eine Rückmeldung vom Controller zu bekommen. Das schlägt fehl, daher hast du einen positiven Funktionstest der Fehleranzeige. Alles gut ;) !)

Also:

MYSENSOR_0   ???

und damit verbundene trim/undef Probleme kommen genau dann, wenn man einfach keine "presentation" in einem Sketch definiert.
Tut man das:
MYSENSOR_0 received presentation
und alles ist in Butter.

Status:

* Ich habe es immer noch nicht geschafft eine Node hinter ein GW zu klemmen, aber mein GW tut jetzt auch mit Sensoren/Aktoren dran
=> Muss ich noch tüfteln

* Obwohl ich "repeater mode" im GW explizit nicht gesetzt habe, wird es in FHEM gesetzt. Wenn ich es lösche, bleibt es weg (muss ich noch checken ob das auch über einen Restart hinweg so bleibt)

* Gibt es eine elegante Möglichkeit im FHEM einen Button zu definieren "Detach GW" - oder so ähnlich?

Ich würde gerne den Port "mit einem Klick" freigeben, wenn ich da via Arduino IDE ne neue Version draufschiessen will. Momentan muss ich HoBo mit shutdown runterfahren, mangels besseren Wissens um eine bessere Lösung.

* Ich habe es leider auch noch nicht geschafft ein Relais auf dem GW via FHEM zum klicken zu bringen. Jegliche Versuche da power/status zwischen 1 und 0, on/off zu schalten waren fruchtlos-still.

---

Die Black Pills et al. sind fertiggelötet (Stiftleisten) und die teste ich jetzt auch mal. Daumen drücken.

Zitat von: RichardCZ am 14 Mai 2020, 12:56:24
und damit verbundene trim/undef Probleme kommen genau dann, wenn man einfach keine "presentation" in einem Sketch definiert.

OK, können wir auf die "ToDo" nehmen, ist aber low prio.

Zitat
* Ich habe es immer noch nicht geschafft eine Node hinter ein GW zu klemmen, aber mein GW tut jetzt auch mit Sensoren/Aktoren dran
=> Muss ich noch tüfteln

Das wird easy...

Zitat* Obwohl ich "repeater mode" im GW explizit nicht gesetzt habe, wird es in FHEM gesetzt. Wenn ich es lösche, bleibt es weg (muss ich noch checken ob das auch über einen Restart hinweg so bleibt)

Das ist am GW "unnützes Zeug" und an echten Repeater-Nodes nur informatorisch. Heißt (afaik) nur, dass der Arduinos Nachrichten puffern kann und kommt vermutlich nach jeder Presentation wieder.

Zitat* Gibt es eine elegante Möglichkeit im FHEM einen Button zu definieren "Detach GW" - oder so ähnlich?

Ich würde gerne den Port "mit einem Klick" freigeben, wenn ich da via Arduino IDE ne neue Version draufschiessen will. Momentan muss ich HoBo mit shutdown runterfahren, mangels besseren Wissens um eine bessere Lösung.

"Einfach" einen setter mit "noArg" definieren (%sets, https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/00_MYSENSORS.pm#L42 ff), schon kannst du das in der setFn hübsch aufbohren.
Meine Lösung: Auf dem Server liegt keine Arduino IDE => im laufenden Betrieb abstöpseln, an meinen Laptop dran und flashen, wieder anstöpseln. 1 Minute Ausfall alle 2 Jahre statt 1*2-4 Stunden coden und testen (für mich). Kann sein, dass es mit dem OTA-feature auch ginge, die firmware so draufzubeamen, aber für RS485 bräuchte man dazu externen Speicher.

Zitat* Ich habe es leider auch noch nicht geschafft ein Relais auf dem GW via FHEM zum klicken zu bringen. Jegliche Versuche da power/status zwischen 1 und 0, on/off zu schalten waren fruchtlos-still.

Der setter wäre "statusn" (die ChildID für n muß eine 1 oder höher sein, afaik). Notfalls mal wieder einen aktuellen Sketch zeigen und ein list einstellen. Es gibt auch erweiterte Möglichkeiten, wenn man das Relais zum state-Reading erklärt, wie es das attrTemplate "A_24a_Relay_Actuator" exemplarisch für status1 vorführt (es kann aber immer nur eines geben, das man so "bevorzugt"). Jedenfalls: dann kann man auch "set MYSENSORS_0 on-for-timer 60" nehmen, um das Relais eine Minute anzumachen, und mit dem attrTemplate sieht man dann auch, dass ein timer läuft ;) ...

Zitat
Die Black Pills et al. sind fertiggelötet (Stiftleisten) und die teste ich jetzt auch mal. Daumen drücken.

Daumendrück!

Das Relais klickt!  :) aus einem HoBo static image heraus. (Arduino Nano hardware)

---

Black Pill leuchtet zwar, und zeigt sich auch

Bus 001 Device 016: ID 1eaf:0004 LeafLabs Maple

aber ansonsten mag der mich ned. Ich habe aber auch zugegebenermaßen noch 0 die Peilung.
Selbst nach nach zig Webseiten, zig YouTube Videos und mittlerweile perfekter Spracherkennung von Indian-English komme ich irgendwie nicht weiter.

Der Reihe nach:

Arduino IDE tut ja mit nano
Board definitions habe ich geladen, auch den STMcube
sogar dfu-util

/etc/udev/rules.d/45-maple.rules

ATTRS{idProduct}=="1001", ATTRS{idVendor}=="0110", MODE="664", GROUP="plugdev"
ATTRS{idProduct}=="1002", ATTRS{idVendor}=="0110", MODE="664", GROUP="plugdev"
ATTRS{idProduct}=="0003", ATTRS{idVendor}=="1eaf", MODE="664", GROUP="plugdev" SYMLINK+="maple"
ATTRS{idProduct}=="0004", ATTRS{idVendor}=="1eaf", MODE="664", GROUP="plugdev" SYMLINK+="maple"

Vermutlich nicht notwendig, aber was tut man nicht alles wenn man verzweifelt ist. /dev/ttyUSB - nada.

Wie auch immer, dmesg sieht relativ schön aus, so lange ich nicht BOOT0 jumper auf 1 setze.

[174435.167336] usb 1-2: new full-speed USB device number 34 using xhci_hcd
[174435.308776] usb 1-2: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[174435.308782] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[174435.308785] usb 1-2: Product: Maple 003
[174435.308787] usb 1-2: Manufacturer: LeafLabs
[174435.308790] usb 1-2: SerialNumber: LLM 003
[174436.658446] usb 1-2: USB disconnect, device number 34
[174436.947345] usb 1-2: new full-speed USB device number 35 using xhci_hcd
[174437.092420] usb 1-2: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[174437.092426] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[174437.092429] usb 1-2: Product: Maple
[174437.092432] usb 1-2: Manufacturer: LeafLabs

Ich vermute(!) ich habe einen Maple Bootloader 2.0. Wenn ich also als upload method den hernehme und Boot0 jumper auf 1 setze, und versuche das Blink-Programm upzuloaden, dann kommt nach ungefähr 100 Jahren Timeout:

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
dfu-util: Invalid DFU suffix signature
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: No DFU capable USB device available
Waiting for /dev/ttyS0 serial...Done

Aber das wundert mich nicht so, denn als Port ist stur /dev/ttyS0 angegeben, ich hätte schon erwartet, dass das über /dev/ttyUSB0 oder so gehen muss, aber den gibt es unter /dev auch nicht.

*krächz*

Zitat von: RichardCZ am 14 Mai 2020, 18:01:06
Das Relais klickt!  :) aus einem HoBo static image heraus. (Arduino Nano hardware)

Dann also: Willkommen in der MySensors-Welt :) .

ZitatBlack Pill leuchtet zwar, und zeigt sich auch

Ähm, dazu hatte ich ja geschrieben, dass STM32 eine ganz andere Welt ist als "normale" Arduinos und eine ganze Ecke komplexer. (oder hatte ich das wirklich unterschlagen?!?).

In der Regel kommen die STM32-Dinger ganz ohne Bootloader, was bedeutet, dass du das als erstes erledigen mußt. Am einfachsten mit einem USB-Seriell-Wandler (A9/A10), und zwar am besten dann den BL nehmen, mit dem man weitere Flash-Vorgänge über USB machen kann (weiß grade nicht, wie der genau heißt).

Zitat von: Beta-User am 14 Mai 2020, 18:07:59
Dann also: Willkommen in der MySensors-Welt :) .
Ähm, dazu hatte ich ja geschrieben, dass STM32 eine ganz andere Welt ist als "normale" Arduinos und eine ganze Ecke komplexer. (oder hatte ich das wirklich unterschlagen?!?).

In der Regel kommen die STM32-Dinger ganz ohne Bootloader, was bedeutet, dass du das als erstes erledigen mußt. Am einfachsten mit einem USB-Seriell-Wandler (A9/A10), und zwar am besten dann den BL nehmen, mit dem man weitere Flash-Vorgänge über USB machen kann (weiß grade nicht, wie der genau heißt).

Deswegen wollte ich ja nicht ganz hardcore gehen und habe einen "mit Arduino Bootloader" bestellt. Na gut, stocher ich noch ein wenig im Trüben.

Hmm, da kommt aus den Untiefen meiner wenigen Erinnerungen noch das Thema "schnell sein" hoch (ich habe das jetzt nicht nochmal recherchiert):

Die MCU muß im BL-Modus sein, wenn du flashen willst. Bedeutet: Innerhalb der einen Sekunde, die die MCU sich als idProduct=0003 zu erkennen gibt, müßte dann auch der flash-Vorgang gestartet werden. Also reboot-Taste drücken und praktisch gleichzeitig den flash-Befehl absetzen sollte gehen.

Ansonsten ist es m.E. besser, diesen anderen BL zu flashen, mit dem man das Ding zum USB-Stick machen kann und dann einfach "drag&drop" die firmware draufkopiert (sowas gibt es jedenfalls dem Hörensagen nach).

Aber vielleicht gibt dir auch noch einer unserer Maple-Erfahreneren einen Tipp?

Uga uga ... ich habe Feuer gemacht!

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 [                         ]   0%            0 bytes
Download [=                        ]   5%         1024 bytes
Download [==                       ]  10%         2048 bytes
...jaja passt scho'
Download [=========================] 100%        18264 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Waiting for /dev/ttyACM0 serial...Done

Bislang nur dieses "Blinking LED Example", aber immerhin. Wer mich jetzt fragen würde, "was das Problem war"... fragt nicht.  ;)

...klingt gut...

Dann würde ich mal als nächstes versuchen, den als GW zu flashen, als Sketch könnte der hier passen (weiß aber nicht, ob der _noch_ funktioniert, aber so viel steht da auch nicht drin): https://github.com/ranseyer/MySensors-HW/tree/master/Experimental/GW-STM32-RS485-RFM/Sketch/MyS-GW-MAPLE-RS485

Zitat von: Beta-User am 15 Mai 2020, 11:56:45
...klingt gut...

Dann würde ich mal als nächstes versuchen, den als GW zu flashen, als Sketch könnte der hier passen (weiß aber nicht, ob der _noch_ funktioniert, aber so viel steht da auch nicht drin): https://github.com/ranseyer/MySensors-HW/tree/master/Experimental/GW-STM32-RS485-RFM/Sketch/MyS-GW-MAPLE-RS485

Mache ich. Aber als aller-allererstes, versuche ich den bisherigen GW Sketch mit dem ich das Relais auf dem GW vie FHEM/HoBo geschaltet habe auf den STM zu bekommen.

HW abstraction layer habe ich dank "Use the Source Luke" hinbekommen (muss man ja auch erstmal das magische define finden).
Vermutlich fehlen mir noch irgendwelche Dateien.

libraries/MySensors/hal/architecture/STM32F1/MyHwSTM32F1.h:23:10: fatal error: libmaple/iwdg.h: No such file or directory
   23 | #include <libmaple/iwdg.h>
      |          ^~~~~~~~~~~~~~~~~

Da muss man durch - aber wird schon...

Kleine Bitte:

Vielleicht direkt (kurze) Notizen machen, was man für die STM32-Geschichte als "from the scratch" Einsteiger zusätzlich tun muß (board-def, libs, ...). Dann kann ich das entweder in den Starter-Guide als "STM32-Specials" einfügen, oder du kannst das ggf. einfacher in Richtung MySensors.org addressieren, dass die fixen, wenn etwas an Referenz fehlt, weil der betr. Entwickler halt schon was installiert hatte, was andere nicht haben?

Zitat von: Beta-User am 15 Mai 2020, 12:33:45
Kleine Bitte:

Vielleicht direkt (kurze) Notizen machen,

Das sowieso - verlass Dich drauf. Mein Blut, Schweiß und Tränen soll ja nicht umsonst geflossen sein.

Nachtrag:

MySensors GW auf einem Black Pill "läuft".

Ich bekomme connected, einen heartbeat, und weil ich EXTENDED_DEBUG eingeschaltet habe, bekomme ich
(nach ein wenig mehrmaligem Drücken) auch

XDBG_CPU_FREQUENCY   720   2020-05-15 17:56:14
XDBG_CPU_VOLTAGE     3296  2020-05-15 17:56:14
XDBG_FREE_MEMORY     0     2020-05-15 17:56:14
heartbeat            alive 2020-05-15 17:57:08

Gut, da wird man vermutlich die Größen anpassen wollen und ich kann das sogar testen. ;-)
Leider bekomme ich es nicht mehr hin das Relais zu schalten  :( - kann aber sein, dass ich einfach nur wieder vergessen habe wie das geht.

---

Aber ein paar Stichpunkte kann ich hier loswerden, nur als Textsammlung gedacht, später kann man das noch in Struktur bringen.

* Wirbelsäulenbruch bei der Dokumentation

Es gibt bei Arduino/STM32 etwas, was ich die Ungnade der späten Geburt nennen möchte. Offensichtlich ist mal stm32duino.com 2019 für längere Zeit (mehrere Monate so wie ich das sehe) abgeraucht und man konnte nicht mehr alle alten Artikel wiederherstellen. https://www.stm32duino.com/viewtopic.php?f=61&t=8

Also trifft man im Verlauf der Recherchen immer wieder mal auf links wie "siehe hier nach: https://www.stm32duino.com/viewtopic.php?f=2&t=873" ... naja  ::)

* Mehrere Wege führen nach Rom, manche sind älter

Mein Erfolgserlebnis mit dem "STM32 Blink" war mit einer komplett anderen Infrastruktur erzielt worden als man für MySensors braucht. Hierzu hatte ich "einfach"
gemäß https://github.com/stm32duino/wiki/wiki/Getting-Started die Board-Definitionen geladen. Ich dachte, dies sei der Standardweg.
Aber mit diesen kommt z.B. keine libmaple.

Man mus tatsächlich vorgehen wie bei https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation beschrieben - zumindest wenn man MySensors laufen lassen möchte.

* Es ist schon eine eigene Welt

Viele neue Begriffe, von denen manche irgendwie das Gleiche meinen, Hardware, die "so in etwa" gleich ist, aber doch nicht ganz...

Die (schwarzen) RobotDyn "Black Pills" - mit denen ich mittlerweile sehr zufrieden bin und erstmal als tadellos betrachte, werden von RobotDyn selbst als "Blue Pills" bezeichnet, vermutlich ist das SEO geschuldet - der Neuling steht erstmal doof da. Es gibt Bilder von "Black Pills", die sehen aber anders aus (chip 45° geneigt) als die mir vorliegenden (chip parallel bzw. rechtwinklig zu Platinenrand). Da muss man dann erstmal nach Gefühl "Interpolieren". Das Wichtigste Orientierungsmerkmal ist der chip: STM32F103

Dazu kommen noch verschiedene Aliase. So nennt RobotDyn (und seine Wiederverkäufer) den vorinstallierten Bootloader "Arduino Bootloader". Sowas gibt es aber nicht und als Neuling kratzt man sich den Kopf. Man vermutet, man hat einen Maple 2.0 Bootloader, und in der Nomenklatur der alten STM32 Infrastruktur hat man den wohl auch.

In der Nomenklatur der "MySensors-relevanten" Infrastruktur ist das der "STM32duino bootloader".

Ich mache jetzt ein paar Tests mit FHEM um sicherzugehen, dass die Fehler die ich sehe nicht HoBo-bedingt sind.

Wenn ich bei attr MYSENSOR_0 einfach nur mapReading__\.+ auswähle, kommt

jquery.min.js line 2:
Uncaught Error: Syntax error, unrecognized expression: a[name=mapReading_\.+]

Das gilt offensichtlich für alle Attribute, die das ".+" zeigen

Hmm, also:

Nach meinem Eindruck sind das eher allgemeine Themen, ohne damit behaupten zu wollen, dazu wirklich was tiefgreifendes sagen zu können.

1. Könnte es sein, dass das immer kommt, wenn man irgendwo ein "Freitextfeld" bei einem Attribut hat? Also völlig unabhängig von der Device-TYPE? Dieser js-Fehler deutet jedenfalls darauf hin, dass es was allgemeines ist und sollte daher gesondert adressiert werden (=>FHEMWEB?).

2. Diese "wildcard"-Attribute sind was sehr spezielles, die kann man gar nicht "richtig" über das danebenstehende Textfeld füllen. Das geht nur über die "Kommandozeile" bzw. das "grüne Plus", und man braucht es auch im MySensors-Kontext in der Regel nicht, weil die betreffenden "Endmappings" normalerweise automatisch angelegt werden. Die Funktionsweise ist eher die, dass "Freitext" als Attributname zulässig wird. Sowas gibt's mindestens auch noch bei der "Schwester" MQTT_DEVICE und (sehr verbreitet) bei HTTPMOD.

Momentan löse ich Elektronikfragen. Naja lösen... sagen wir ich stochere wieder im Trüben, weil dafür bin ich nun wirklich nicht qualifiziert genug.

Ich konnte das Relais aus FHEM heraus auf meinem Black Pill schalten - allerdings nur genau einmal, seitdem will der Ausgang nimmer.  :P
Pro Pin werden ~20mA empfohlen. Das Relais allerdings zieht laut Datenblatt (erst im Nachhinein angeschaut) ~ 70mA. Filmtitel wie "Die hard" oder 300! kommen einem in den Sinn.

Mit dem Nano alles kein Problem, jetzt erscheint er mir schon fast barbarisch robust. der STM32 braucht da wohl einen "Treiberschaltkreis" - besagte Elektronikfragen s.o.

Das Netz empfiehlt da z.B. einen 74HCT245 (https://forum.makerforums.info/t/ive-been-working-with-a-3-3v-device-stm32-blue-pill/60631/2), da muss ich erstmal meinen lokalen Dealer behelligen.

Oder einfach ein MosFET ....

oder jene, gehen bis 50 V am Ausgang.

https://www.conrad.de/de/ratgeber/handwerk-industrie-wiki/elektronik-bauteile/uln2803.html (https://www.conrad.de/de/ratgeber/handwerk-industrie-wiki/elektronik-bauteile/uln2803.html)

Da gibt es inzwischen auch neuere Versionen/Typen, da fällt mir gerade keine aktuelle Bezeichnung ein

Freilaufdiode kann auch nicht schaden

Zitat von: fhem-hm-knecht am 16 Mai 2020, 22:46:48
oder jene, gehen bis 50 V am Ausgang.

https://www.conrad.de/de/ratgeber/handwerk-industrie-wiki/elektronik-bauteile/uln2803.html (https://www.conrad.de/de/ratgeber/handwerk-industrie-wiki/elektronik-bauteile/uln2803.html)

Da gibt es inzwischen auch neuere Versionen/Typen, da fällt mir gerade keine aktuelle Bezeichnung ein

Das klingt ähnlich wie das hier bei meinen Recherchen gefunden: https://hackaday.io/project/21396-stm32-blue-pill-iot-expansion-boards

Bei diesem PIO Board verwendet er einen (eigtl. gleich 3) ULN2804A

"extensive PIO number x24 PIO s from which x12 PWM
power outputs x500 mA 50V compared to uC pio of 25mA 3V"

Das ist toll, aber 50V? Ich brauche doch nur 5.  ???

Oder kann ich den auch mit nur 5V betreiben? Wenn ja, wäre das die Lösung. Dieser 74HCT245 kann offensichtlich auch nur insgesamt 70mA und pro Pin max 35mA - also max 2 Pins "unter Last" und für die 70mA des Relais langt das eh nicht.

Zitat von: herrmannj am 17 Mai 2020, 00:57:11
Freilaufdiode kann auch nicht schaden

Gehe ich mich fortbilden was eine Freilaufdiode ist und wie da die Schaltung aussehen würde.

edit:

Alles klar! Alter Schwede - diese Conrad Seite, das ist ja wie für 5-Jährige geschrieben, also genau was ich gebraucht habe.
Jetzt ist mir alles klar. Morgen wird der nächstbeste Elektronikladen gestürmt.

Zitat von: RichardCZ am 14 Mai 2020, 12:56:24
und damit verbundene trim/undef Probleme kommen genau dann, wenn man einfach keine "presentation" in einem Sketch definiert.

Hmm, also:
Dann scheint das damit zusammenzuhängen, dass "state" undef ist und bleibt. Da 10_MYSENSORS_DEVICE.pm noch nicht so lange überhaupt was in state schreibt (also 3? "ewig" der Normalzustand war), vermute ich kein Problem auf der Seite der Module, sondern eher in der allgemeinen Infrastruktur. Mir wäre jedenfalls neu, wenn es irgendwo eine Vorgabe gäbe, dass "state" einen Inhalt haben muß.

Zitat von: RichardCZ am 15 Mai 2020, 13:10:30
Aber ein paar Stichpunkte kann ich hier loswerden, nur als Textsammlung gedacht, später kann man das noch in Struktur bringen.

Habe das mal als Basis genommen und hier "verwurstet":
https://wiki.fhem.de/wiki/MySensors_Starter_Guide#Andere_Microcontroller
Falls Handlungsbedarf besteht, bitte melden, dto. für spätere Ergänzungen.

Zitat von: RichardCZ am 15 Mai 2020, 13:10:30
Ich bekomme connected, einen heartbeat, und weil ich EXTENDED_DEBUG eingeschaltet habe, bekomme ich
(nach ein wenig mehrmaligem Drücken) auch

XDBG_CPU_FREQUENCY   720   2020-05-15 17:56:14
XDBG_CPU_VOLTAGE     3296  2020-05-15 17:56:14
XDBG_FREE_MEMORY     0     2020-05-15 17:56:14

Gut, da wird man vermutlich die Größen anpassen wollen und ich kann das sogar testen. ;-)

Na ja, da bin ich nicht sicher, ob das Problem auf der Seite der Module liegt oder ob die Debug-Infos nicht schlicht für den ATMega328 ausgerichtet sind (oder ATMega allg.). (Es ist aber zugegebenermaßen ähnlich wie bei den ersten Rückmeldezeiten: hat an sich funktioniert (auch Memory), wen scheren da Einheiten...?)

Weiß jemand wie man mit MySensors eine Frequenzmessung auf der Stromleitung durchführen könnte?

Mir reicht/interessiert der Bereich 48-55 Hz - dafür aber auf 1/100stel Hz genau.

Na ja, eigentlich ist das ja keine wirkliche MySensors-Frage, oder? Es gibt für Frequenzen innerhalb des Frameworks afaik keinen direkt passenden Datentypen, ich würde vermulich eben irgendwas nehmen (S_CUSTOM, wenn einem gar nichts einfällt), oder eben was, was in die richtige Richtung geht (V_VAR aus S_POWER?).

Die Messung selbst? Hmm, alles was mit 230V zu tun hat, ist immer mit einer gewissen Vorsicht zu "genießen". Suche nach "arduino frequency power" führt z.B. zu https://create.arduino.cc/projecthub/indoorgeek/measure-mains-frequency-using-arduino-8013b7 (https://create.arduino.cc/projecthub/indoorgeek/measure-mains-frequency-using-arduino-8013b7). Dahinter scheint die Idee zu stecken, die 230V mit einem ordinären Trafo auf 12V Wechselspannung runterzuholen und dann die Pulse interrupt-basiert zu zählen. Dann kann man alle Naselang nachsehen, wie viele es denn waren. Wenn man die reduzierte Wechselspannung über einen Optokoppler an den Arduino bringt, sollte sich das halbwegs gefahrlos (für den Arduino :P ) austesten lassen...
Ob es dafür besseres und sichereres Equipment gibt: k.A..

EDIT (Oder statt des Optokopplers einen Transistor, siehe https://i0.wp.com/www.electroniclinic.com/wp-content/uploads/Arduino-Project-Power-line-frequency-or-mains-frequency-Monitoring-%E2%80%9CAC-220V-Frequency-monitoring%E2%80%9D-image8.png?ssl=1)

Zitat von: Beta-User am 20 Mai 2020, 13:53:00
Na ja, eigentlich ist das ja keine wirkliche MySensors-Frage, oder?

Ich hatte schon gehofft, dass jemand so ein "Shield" hat.

Zitat
Es gibt für Frequenzen innerhalb des Frameworks afaik keinen direkt passenden Datentypen, ich würde vermulich eben irgendwas nehmen (S_CUSTOM, wenn einem gar nichts einfällt), oder eben was, was in die richtige Richtung geht (V_VAR aus S_POWER?).

Das war/wäre der nächste Punkt meiner Frage gewesen: Falls man eine HW-Lösung hat - wie knüppelt man das in das Protokoll?

Zur Erklärung: In einem Mikrogrid PV System wird die Leistung der PV Inverter über die Netzfrequenz gesteuert

Start       50.2 Hz
Minimum     52.7 Hz
Disconnect  53.0 Hz
(siehe https://www.victronenergy.com/live/ac_coupling:fronius)

Wenn man die Netzfrequenz kennt, kennt man also auch das Maß der Drosselung und folglich die "potentielle Leistung" und folglich die ungenutzten Reserven, die z.B. via Heizstab o.ä. verheizt werden könnten anstatt brach zu liegen.

Ich kann vermutlich diese Info direkt von den Victrons bekommen via MQTT, dachte mir aber, dass es evtl. ganz nett wäre das mal dezentral - sozusagen P2P innerhalb des MySensors Netzwerks lösen zu können. Vermutlich nichtmal P2P, es könnte eine Node machen, die eh im Maschinenraum hängt. Die würde Frequenz messen und gleich die entsprechenden verbraucher (stufenlose Heizelemente) schalten.

Die Steuerung wäre sozusagen Bestandteil des Node-Sketches (Platz ist im Black Pill genug da) und würde nur die Werte ans GW liefern, aber nicht "remote gesteuert werden". Könnte man natürlich noch beliebig ausbauen, aber erstmal Gemach. Einen Aktor habe ich schon, nur hinsichtlich Sensor habe ich nur Strommessung (Hall Sensor) aber keine Frequenzmessung.

Interessante Überlegung, und auch die dezentrale Auslegung der Logik finde ich einen guten Ansatz.

Zitat von: RichardCZ am 20 Mai 2020, 15:13:00
Das war/wäre der nächste Punkt meiner Frage gewesen: Falls man eine HW-Lösung hat - wie knüppelt man das in das Protokoll?

Die Antwort war also: irgendwie... Letztendlich müssen ja nur alle Beteiligten (Node, GW, FHEM, User) wissen, wie ein Wert zu verstehen ist; aber Datentechnisch spricht z.B. auch nichts dagegen, das als Temperatur- oder Helligkeitssensor zu präsentieren, das irritiert dann nur die letzte Stufe in der Infokette (also den User).

Btw.: hatte gestern etwas Muße und habe mal einen MCP2551 direkt an einen USB-Seriell-Wandler angeschlossen. Eigentlich vorrangig um zu sehen, ob ich damit zufällig irgendwelchen Datenverkehr an meiner Therme sehe (Junkers HT-Bus, der Hinweis von @Ranseyer zum Easy-Bus hat mich auf diese Idee gebracht, weil der ja auch ständig 5V Differenzspannung A-B bringt, ganz wie die vermutete Bus-Anschlussstelle am HT-Bus). Das hat nicht geklappt, aber zum Testen habe ich die Konstruktion mal zum Sniffen des MySensors-Verkehrs benutzt. War interessant, und vor allem irgendwie beruhigend. Denn jedenfalls in der kurzen Zeit des sniffens kam eigentlich nur das "als Klartext" über die Leitung, was offensichtlich Text war (Sketchname und Sketchversion), der Rest war zwar irgendwie strukturiert, aber im Prinzip unleserlich. Ergo kann ein Angreifer, der die Leitung findet zwar Sniffen oder sich ganz einklinken, aber er muß dazu wissen, dass es MySensors ist, was da läuft (und dann noch die Datenrate kennen, wie üblich). Nett...

Zitat von: Beta-User am 20 Mai 2020, 15:33:03
Ergo kann ein Angreifer, der die Leitung findet zwar Sniffen oder sich ganz einklinken, aber er muß dazu wissen, dass es MySensors ist, was da läuft (und dann noch die Datenrate kennen, wie üblich). Nett...

Trotzdem ist das nur security by obscurity.
Und vermutlich werde ich es - in der Kabelfassung - auch dabei belassen, aber bei einer drahtlos Lösung würde die Entscheidung schon anders aussehen.

Nur mal so als Stand: Ich bin nicht tot, ich bin am basteln.

ULN2803A
74HC165
74HCT245
74HC595

wollen zusätzlich zu dem Experimentierzeug (siehe Bilder oben "Materialschlacht") getestet werden.
"Gute" Nachricht - das Relais was aufgehört hat zu klackern - da ist nicht der uC Ausgang kaputt, sondern das Relais.
Hat in seinem Leben so 10x geschaltet. Werde mich vermutlich nach SSRs umsehen.

edit:

vielleicht noch als Nachtrag zum "bin am Basteln":

Definitiv sei jedem Anfänger und vielleicht auch jedem "ambitionierten Anfänger" empfohlen sich auf alle Fälle zumindest zwei Arduinos zu holen - auch wenn er mit STM32-basierten Nodes plant. Nicht wenige Bibliotheken fliegen einem nämlich um die Ohren, wenn man die "mal eben" auf dem STM32 compiliert. So geschehen gestern mit der u8glib:

WARNING: library U8glib claims to run on avr, sam architecture(s) and may be incompatible with your current board which runs on STM32F1 architecture(s).

Das kann man sich ja dann als ambitionierter Anfänger zu herzen nehmen: https://blog.bastelhalde.de/post/using-the-u8glib-on-the-stm32
aber für einen schnellen Test des aquirierten Materials ist es eher hinderlich in den Basisbibliotheken rumzuhacken.

In dem Fall reicht mir security by obscurity ;D . War jedenfalls besser als nRF ohne signing (das kann man da optional in Hardware ergänzen, die RFM-Chips sollten das sogar built-in können). Theoretisch könnte das mit signing auch bei RS485 gehen, aber "obscurity" war für mich bisher ausreichend, um deswegen nicht schlaflose Nächte zu haben...

ULN2803A habe ich jüngst auch ein paar bestellt, das klang sinnvoll, das mit den Schieberegisterdinger ist vielleicht auch noch eine gute Sache (mir sind die Pins an den Arduinos bisher allerdings nicht ausgegangen, und großflächige LED-Anzeigen wollte ich eigentlich nicht aufbauen, da ist ein Blick auf's Handy aufschlussreicher), aber für was sind die 74HCT245 gedacht? Das klingt "speziell".

Was das Relay angeht: shit happens, aber ausgerechnet beim ersten?!? Die Dinger sind nach meiner Erfahrung eher robust...

Wie auch immer: Viel Spaß beim weiteren basteln!

(OT: bisher hat sich keiner über das update der Module beschwert, aber (außer dir) auch keiner irgendwas zu den neuen features rückgemeldet. Strange, und hoffentlich eher beruhigend).

Zitat von: Beta-User am 20 Mai 2020, 16:25:11
aber für was sind die 74HCT245 gedacht? Das klingt "speziell".

3.3V <-> 5V Interface. Ich habe mir auch 2 Büchlein besorgt:

Mastering STM32 von Carmine Noviello
Beginning STM32 von Warren Gay

In letzterem steht auf Seite 300 eine Application note wie man z.B. ein PWM Signal zwischen der Pille und einem Servomotor mittels dieses Chips "konvertiert".
Da er bidirektional ist, kann er auch dienen die nicht-5V-toleranten Eingänge der pille zu schützen.

Ansonsten siehe: https://www.mikrocontroller.net/articles/Pegelwandler

Ah, so einfach ist die Welt manchmal. Man muß nur draufkommen...

Die Frage ist auch, was Du mit dem Relais geschaltet hast. Speziel bei Induktiven lasten ist das Leben von Relais als "kurz" zu betrachten .. was ich selber mal schmerzlich Erleben durfte.

Auch sind "echte" Umschalter, wo also der Öffner und der Schließer belegt sind, zu vermeiden. Dann lieber 2 Relais parralel, also bei einem den Öffner und beim anderen den Schließer ...

Zitat von: Wernieman am 21 Mai 2020, 10:59:06
Die Frage ist auch, was Du mit dem Relais geschaltet hast. Speziel bei Induktiven lasten ist das Leben von Relais als "kurz" zu betrachten .. was ich selber mal schmerzlich Erleben durfte.

Auch sind "echte" Umschalter, wo also der Öffner und der Schließer belegt sind, zu vermeiden. Dann lieber 2 Relais parralel, also bei einem den Öffner und beim anderen den Schließer ...

Nichts habe ich geschaltet. Ausgänge waren frei, mir ging's nur um das *klack* *klack* zum Testen.

Naja - ist so ein < 2EUR Teil, da lohnt nichtmal die Reklamation. Kann natürlich Pech sein, "Badewannenkurve" - also der Anfang davon, falsche Charge erwischt.
Aber das produktiv zu verwenden hat jetzt schon einen Dämpfer erhalten.

Zitat von: RichardCZ am 20 Mai 2020, 15:59:38
vielleicht noch als Nachtrag zum "bin am Basteln":

Definitiv sei jedem Anfänger und vielleicht auch jedem "ambitionierten Anfänger" empfohlen sich auf alle Fälle zumindest zwei Arduinos zu holen - auch wenn er mit STM32-basierten Nodes plant. Nicht wenige Bibliotheken fliegen einem nämlich um die Ohren, wenn man die "mal eben" auf dem STM32 compiliert. So geschehen gestern mit der u8glib:

WARNING: library U8glib claims to run on avr, sam architecture(s) and may be incompatible with your current board which runs on STM32F1 architecture(s).

Das kann man sich ja dann als ambitionierter Anfänger zu herzen nehmen: https://blog.bastelhalde.de/post/using-the-u8glib-on-the-stm32 (https://blog.bastelhalde.de/post/using-the-u8glib-on-the-stm32)
aber für einen schnellen Test des aquirierten Materials ist es eher hinderlich in den Basisbibliotheken rumzuhacken.

Weiß nicht, ob das das Problem vollständig beseitigt:
https://github.com/mysensors/MySensors/pull/1422

Aber auch nach meinem Eindruck sollte man in diese Welt immer mit "möglichst wenig drumrum" einsteigen: zwei Arduinos, zwei (einfache und bekanntermaßen funktionierende) Transceiver, das ganze mit seriellem GW. Komplizierter machen geht immer, selbst wenn es an manchen Ecken nach und nach einfacher wird...