Autor Thema: Incoming  (Gelesen 11972 mal)

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Incoming
« am: 07 Mai 2020, 14:55:18 »
:) 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.

Online gloob

  • Hero Member
  • *****
  • Beiträge: 3128
Antw:Incoming
« Antwort #1 am: 07 Mai 2020, 15:17:06 »
Und dafür braucht es nen neuen Thread?  >:(
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #2 am: 07 Mai 2020, 15:36:12 »
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).
« Letzte Änderung: 07 Mai 2020, 15:43:31 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Wernieman

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6928
Antw:Incoming
« Antwort #3 am: 07 Mai 2020, 15:54:06 »
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 ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline igami

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2716
  • RTFM
    • commandref
Antw:Incoming
« Antwort #4 am: 07 Mai 2020, 16:10:09 »
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 ;)
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #5 am: 07 Mai 2020, 16:16:20 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Gisbert

  • Hero Member
  • *****
  • Beiträge: 2025
  • Das Ziel ist das Ziel !
Antw:Incoming
« Antwort #6 am: 07 Mai 2020, 16:32:01 »
Zitat
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 .
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​
« Letzte Änderung: 07 Mai 2020, 20:47:48 von Gisbert »
Aktuelles Fhem auf HP ThinClient T610 | Debian10 | UniFi-Controller | Homematic, VCCU, HMUART | ESP8266, Platinen von Papa Romeo | Gas-, Wasser-, Stromzähler | Sonoff | 1-Wire-Temperatursensoren | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21RF

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Incoming
« Antwort #7 am: 07 Mai 2020, 17:16:00 »
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".

Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #8 am: 07 Mai 2020, 18:07:22 »
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!

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

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

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

Zitat
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".
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 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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline rob

  • Full Member
  • ***
  • Beiträge: 238
Antw:Incoming
« Antwort #9 am: 08 Mai 2020, 09:21:58 »
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
fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #10 am: 08 Mai 2020, 09:53:25 »
... es hat mir keine Ruhe gelassen:
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

Der eigentliche Transportlayer nennt sich PJON, Quelltext ist hier zu finden: 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:
Zitat
SoftwareBitBang is a software implementation of PJDL (Padded Jittering Data Link). 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 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
« Letzte Änderung: 08 Mai 2020, 10:39:42 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Incoming
« Antwort #11 am: 08 Mai 2020, 14:37:56 »
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?)


Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #12 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!

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".
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Incoming
« Antwort #13 am: 08 Mai 2020, 16:00:20 »
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.


Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1850
Antw:Incoming
« Antwort #14 am: 08 Mai 2020, 16:04:29 »
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire