RS485: Busauslegung und alternativ: CAN-Treiber-Chips?

Begonnen von Beta-User, 22 Februar 2018, 15:14:12

Vorheriges Thema - Nächstes Thema

Beta-User

OK, für weniger rechenaffine Menschen, die mehr auf trial und error stehen:
Im Ergebnis sollte ich einfach mal alle Widerstände runterwerfen, mit Ausnahme von 2 4k7-Widerständen an einem der Busenden?

(da ich sowieso fast alle R's runter habe und irgendwo noch ein LC-Tech-MAX487-Modul mit 4k7-Widerständen rumliegt, wäre das kein großes Ding)...

Werde ich mal angehen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

Hmm, ... Ich wollte dir jetzt nicht persönlich sagen was du tun sollst ;)

Mein Post ist prinzipiell auch nichts großartig neues. Bei einem schnellen und langen Bus muss terminiert werden.

Grund: Die Drähte bilden eine Kapazität diese muss aufgeladen oder entladen werden bei einem Pegelwechsel.

Nun ist meine Idee halt dass bis 500m mit weniger Speed trotz schlampigerem Aufbau (Misch-Stern) ein stabiler Bus möglich sein sollte.

Du könntest mal das Homematic Bild im Wiki anschauen, da machen die Jungs mit dem Spannungsteiler 5V, und die zweite Leitung wird Richtung GND gezogen.


Probieren schadet nicht. Mir ging es eher um Grundlagen. Bei meinem Aufbau war das einzige Problem bisher die Spannungsversorgung. Da muss man in jedem Fall etwas mitdenken.
zum Test kann du die Widerstände an beliebiger Stelle plazieren.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Zitat von: Ranseyer am 24 April 2018, 17:54:15
Hmm, ... Ich wollte dir jetzt nicht persönlich sagen was du tun sollst ;)
Schon klar, dass das hier allg. gilt, und dass ich das ggf. auch auf "eigene Gefahr" mache...
Wir werden sehen. :)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Kurze Zwischeninfo:

Habe vorhin dann einfach mal das "Endmodul" gegen ein CAN-Modul ohne Widerstände getauscht. Funktioniert jedenfalls kurzfristig auch so, die einzigen Widerstände am Bus sind dabei die am GW (auf MAX487 umgelötetes LC-Tech-Modul).

Baudrate ist noch @57600, Kabellänge grob geschätzt irgend was zwischen 30 und 40m. Im Einsatz ist (fast) alles, was ich an Transceivern so rumliegen habe: MAX487, TJA1050 und MCP2551, allerdings sind grade nur 3 Nodes online.

Wie es aussieht, benötigen die CAN-Module halt HW-serial, aber das stört mich eigentlich nicht weiter außer dem Umstand, dass ich dazu etwas umlöten muß und ggf. mittelfristig ein anderes GW einsetzen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Mal wieder ein update zu dem topic, leider habe ich  auch keine wirklichen Durchbrüche zu berichten :( .
- Den gemeinsamen Ground hatte ich verbunden, aber zwischenzeitlich wieder unterbrochen: Bei einer Spannungsunterbrechung auf der 12V-Schiene und Wiederanschalten war (mind) FHEMWEB reproduzierbar nicht mehr zu erreichen. Das unabhängig davon, ob ich mein "normales" Netzteil verwendet habe mit nur einem Euro-Stecker oder ein anderes mit Schuko-Stecker.
Auch solange GND verbunden war, kam es zu Ausfällen, keine wesentliche Änderung der Dauer bis zum Ausfall oä..
- Dann habe ich den Rest der Nodes und das GW (@Pro Micro :D ) vollends auf HW-Serial umgestellt und die Baudrate auf 19200 runter genommen. Da ich jetzt nur noch MCP2551-Transceiver im Einsatz habe, ist auch die DE-PIN-Funktionalität deaktiviert.

- Zum Einsatz kommt eine modifizierte 10_-Device.pm, mit der man heartbeats anfordern kann und diese auch für "alive" auswerten. Daher kann ich jetzt recht gut nachvollziehen, ob das GW nicht mehr durchkommt, oder nur einzelne Nodes ein Problem haben usw. Leider helfen mir diese Optionen nur bedingt: Es läßt sich kein wirkliches Muster erkennen :( , es handelt sich jedenfalls in der Regel nicht um ein "eigentliches" Bus-Problem, da einzelne Nodes, wenn ich sie resette in der Regel einfach wieder den Betrieb aufnehmen... Andererseits liegen die Ausfälle einzelner Nodes gerne nahe beieinander (2 innerhalb 15 Min und so).
-Widerstandswerte habe ich auch hin und her probiert:-- 120 Ohm je nur am GW und Busende-- zuletzt war CANlo-4.7k-GND und GND-4.7-CANhi-10k (bzw. 14.7k)-12V => 6-8 Stunden, bis die letzte nicht mehr will, da hatte ich die 120 Ohm am Busende auch mal weggelassen
-- aktuell: je 2.2k CANlo-GND und CANhi-5VDas werde ich ggf. nochmal reduzieren und auch die Baudrate ggf. auf 9600 runternehmen (kann aber sein, dass das auch für den MCP2551 zu lange dauert, bis ein Signalwechsel kommt)

Für alle derzeit angeschlossenen 4 Nodes zeigt mein Meßgerät beim Start ca. 3.5W an, dann 2.5W. Wenn irgendwas sendet, geht es wieder kurzzeitig auf 3.5W hoch. Auch hier scheinbar also keine offensichtlichen Unregelmäßigkeiten.
Vielleicht hat ja jemand noch eine Idee...
Ansonsten erst mal schönes Wochenende!
Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#80
So, noch ein update :) .
Am WE hatte ich etwas Zeit und Ruhe, außerdem waren zwischenzeitlich ein 5V-Netzteil, Ersatzarduinos sowie weitere CAN-Module (MCP2551, Aufbau wie im Bild unten) angekommen.

Bis dato war an einen stabilen Regelbetrieb eigentlich nicht zu denken, zwei Nodes (die jetzt eigentlich gebraucht werden) waren bis dato vom Netz.

Als erstes wurde das 12V-Netzteil gegen 5V getauscht. Zu meiner Überraschung war dann zwar der Leerverbrauch des Netzteils geringfügig höher, aber nach dem Wiederanklemmen der (unveränderten!) Nodes war er ca. 1W geringer als vorher. Das ist schon mal erfreulich. Alle verbliebenen Nodes haben dann erst mal wieder gesendet, auch erfreulich.

Dann die erste Node mit einem neuen Pro Mini versehen, den LMS1117 für 12V->5V runter und die Spannungsversorgung auf der Node umgelötet, angeschlossen und beim Flashen den alten Code, aber mit der Änderung aus dem Pull-Request #1142 verwendet (ansonsten ist die Lib auf einem 2.3.0-alfa Stand von vor ein paar Wochen).

Als nächstes dann die 5. Node umgelötet (LMS1117 runter), zum Einsatz des og. Moduls vorbereitet und den Arduino geflasht (wieder mit #1142). Angeschlossen: Lief nicht :( . Dann CRX und CTX vertauscht (also Arduino RX nach Modul CRX und TX nach CTX) => online :) .

Pause gemacht und gefreut. Einige Zeit später: die drei "alten" Nodes offline :( , die beiden "neuen" sendeten artig weiter Daten bzw. einen heartbeat :) .
OK. Schlußfolgerung: Entweder es waren die Spannungswandler, die das Problem verursacht haben, und die müssen einfach bei den anderen Nodes noch runter, oder es sind die paar Zeilen Code.

Also habe ich an einer nur die Spannungsversorgung umgelötet und wollte dann eine Zweite nur mit der Codeänderung beglücken. Ersteres funktionierte erst mal problemlos, aber bei der, die nur den geänderten Code bekommen sollte, stand dann offensichtlich nicht mehr genug Saft für einen stabilen Betrieb zur Verfügung. Da muß ich also nochmal ran, die fällt auch im Moment alle Paar Stunden aus und kann auch nicht angepingt werden (keine Reaktion auf heartbeat request).
ABER: Alle anderen laufen seither :) , auch wenn noch nicht alle Sensorik wieder angeklemmt ist (das mache ich dann nach und nach, wenn die Kommunikationsebene verläßlich funktioniert).

Zusammengefaßtes aktuelles Setup also:
- 19200 Baud- ausschließlich MCP2551 als Transceiver, die "alten" umgelötete TJA-Module, eine Node mit dem abgebildeten Modul
- Alle mit HW-Serial ohne DE-PIN-Definition
- GW: ungepatchter Pro Micro, versorgt via USB
- Spannungsversorgung alle anderen Nodes über ein zentrales 5V-Netzteil
- GND ist bei allen über die zentrale Versorgung identisch, mit Ausnahme des GW(-EDIT: GND - 2kOhm - CANlo - 120 Ohm - CANhi - 2kOhm - 5V am Busende).

Jetzt werden jedenfalls erst mal die Spannungswandler auf den verbliebenen Nodes noch ausgelötet und dann wird sich zeigen, ob und wann welche Nodes wieder nicht mehr wollen.
Bin mal gespannt, wann ich das nächste Mal hier öffentlich weine ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

Hallo Beta-USer,
.
dann hoffe ich mal dass es dabei bleibt.

Mein Stand ist inzwischen folgender:
-Der RS485 Bus existiert nun schon ewig und wird sehr viel kommerziell genutzt, auch in der Industrie
-bei mir läuft der superstabil
-natürlich kann es Umsetzungsprobleme geben (z.B. Kabel, Verbindungen, Versorgung, Störungen und fehlende Maßnahmen dazu)

Zweitens könnte ich mir vorstellen dass wir noch immer ein SW Problem haben:
ZitatDa nicht mehrere Sender gleichzeitig auf die Leitung aufgeschaltet sein dürfen, muss der jeweilige Sender nach Bedarf eingeschaltet werden (Halbduplex). Dies wird auf Protokollebene definiert. Der Sender steuert das differentielle Leitungspaar voll aus, d.h. geht unbelastet auf 0V/Vcc, wobei es 3.3V, sowie 5V Bausteine gibt. Unter Last nimmt die Amplitude dann ab. Der Empfänger braucht minimal 70mV Differenzspannung in einem Gleichtaktbereich von -7...+12V. Es gibt auch Bausteine mit höheren Gleichtaktspannungen.
Quelle: https://www.mikrocontroller.net/articles/RS-485

Frage: Hast Du evtl nen Schaltplan zu dem abgebildeten Modul oder ne kurze Beschreibung was da warum drauf ist ? (Angeschlossen hast du nur die ersten vier Pins ? VCC bis CRX?)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Moin,

wenn ich nicht überzeugt wäre, _dass_ es gehen _muss_, würde ich nicht so hartnäckig dran bleiben ;) .
Und ganz sicher ist es so, dass ich mir manche Probleme selber gemacht habe und deswegen hin und wieder im Kreis gelaufen bin, ohne die wahre(n) Ursache(n) zu finden.
Zitat von: Ranseyer am 12 Juni 2018, 08:53:49Zweitens könnte ich mir vorstellen dass wir noch immer ein SW Problem haben.
Es gibt dazu ja auch längere Diskussionen auf MySensors.org, ob RS485(@MAX48x) denn wirklich funktionieren kann und ob man nicht eine andere kabelgebundene Lösung bevorzugen sollte. Das Grundproblem ist eben, dass klassisches RS485 kein Multi-Master-Konzept ist, wie es für die bisherige Struktur von MySensors erforderlich wäre. Von daher ist das Thema Collission-Detection nach allem, was ich dazu gelesen habe von zentraler Bedeutung.

Was meine bisherigen Erfahrungen angeht, läßt sich eine gewisse Tendenz feststellen: Sehr häufig lagen die Ausfälle der Nodes zeitlich eng beieinander. Das kann eigentlich nur dadurch kommen, dass entweder der Bus elektrisch ein Problem hat (insbesondere: eine Node auf Dauer-Sendung oder ein "weglaufender" GND) oder alle Nodes wegen irgendetwas die eigene Kommunikation eingestellt haben, was wiederum elektrische (Abschaltung wg. Hitze) oder logische (Code) Ursachen haben kann.
Das mögliche Dauer-High durch hängengebliebene einzelne Arduinos sollte seit Umstellung auf CAN-Transceiver faktisch ausgeschlossen sein. Tatsächlich war es jedenfalls die letzte Zeit, teilweise aber auch schon vorher, in der Regel möglich, einzelne Nodes bzw. alle nacheinander wieder online zu bringen, indem man den Reset-Knopf drückte. Das sollte eigentlich die Transceiver auch nicht stromlos gemacht haben (die hängen/hingen direkt hinter den 12V-5V-Wandlern), was noch mehr dafür spricht, dass es ein Problem auf den Arduinos ist. Das läßt auch darauf schließen, dass es nicht mit der Frage der korrekten GND-Verbindung zusammenhing/-hängt.

Damit bleibt die wahrscheinlichste Ursache ein fehlerhafter Umgang mit zeitgleichen Sendungen bzw. Sendungsversuchen auf dem Bus.

ZitatFrage: Hast Du evtl nen Schaltplan zu dem abgebildeten Modul oder ne kurze Beschreibung was da warum drauf ist ? (Angeschlossen hast du nur die ersten vier Pins ? VCC bis CRX?)
Schaltplan habe ich keinen, aber die Belegung dieser Module ist eh' minimalsitisch, gute Bilder wären hier zu finden. Auch auf den TJA-Modulen ist nicht wirklich viel drauf, Bild hier, aber eben R121 bei den Zwischennodes runter und MCP2551 statt des TJA.
Angeschlossen ist immer Arduino:5V, GND, Rx, Tx <-> Modul 5V, GND, RX bzw. CTX, TX bzw. CRX. Und dann eben noch die Bus-Anschlüsse zum Bus hin (muß nochmal prüfen, ob die gemoddeten TJA-Module wirklich Rx-TX-vertauscht anzuschließen sind, aber egal, der Teil scheint ja zu funktionieren, und wenn man es falsch macht, funktioniert es auch kurzfristig nie ::) ).

Aktueller Zwischenstand übrigens:
Gestern abend sind dann pünktlich nach dem Abendessen die beiden Nodes mit dem "alten" Code ausgefallen (eine davon schon auf 5V-Versorgung umgebaut). Daher haben die jetzt auch noch die 4 Zeilen zusätzlich erhalten. Bisher senden sie artig, mal schauen, wie lange...

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Hallo zusammen,

weiterhin alles online :) .

Bei Gelegenheit werde ich dann mal testen, ob die MCP2551-CAN-Transceiver auch mit AltSoftSerial können (dann wird vielleicht auch das mit der RFID-Leser-Node endlich was...).
Das wäre super, weil man dann "das beste aus allen Welten" hätte. Einziger Nachteil, den ich sonst (neben dem obigen offenen Punkt mit AltSoftSerial) bisher an der CAN-Lösung sehe: die Message-Length ist begrenzt; das scheint aber für die normale MySensors-Funktionalität irrelevant zu sein.
Weiterer Vorteil: PIN2 wird auch noch frei - damit kann man am Nano/Pro Mini beide "echte" Interrupt-PINs anders nutzen!

Da hier noch ca. 10 von den Dingern als SOIC-8 rumliegen (sind aber leider nicht PIN-kompatibel mit MAX48x, passen also nicht auf die bisherigen Platinen): Wenn jemand testen möchte, bitte um Adresse per PN (für ernsthafte Tester bis 5 St. umsonst). 
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

Ich hab ernsthaftes Interesse, habe aber selbst ein paar bestellt, und werde diese nur auf Platinen verbauen. (Und bis ich diese da habe habe ich sicher auch die Chips)

Evtl. passe ich diese darauf an:
https://github.com/ranseyer/MySensors-HW/blob/master/Experimental/GW-Sens-RS485-ProMicro/top-01.png
Die ist echt winzig geworden und trotzdem sehr mächtig.
((Und dann kommt wieder die Frage auf: Mega32U4 und MySensors... - Ich habs noch nicht probiert, Ansonsten müsste der ProMini drauf))
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Sieht cool aus!
Als GW nutze ich übrigens auch einen ProMicro mit HW-Serial. Ist optisch aber deutlich provisorischer, meine "Lötfähigkeiten" sind ja hinlänglich berüchtigt... Das Problem ist "nur", dass man einen Reset-Taster braucht, um den Bootloader zu starten, und die Erfolgskontrolle des Flashens ist etwas diffiziler. Aber ansonsten funktioniert das problemfrei (seit einigen Wochen, wann das war hatte ich in dem anderen Post zum ProMicro gepostet, oder?).

(Das GW hat übrigens als einziges den Patch noch nicht...)

Also wenn du die Option hast, irgendwo den Taster noch draufzudesignen, wäre das vermutlich hilfreich, und nach dem 120-er Widerstand habe ich jetzt nicht gesucht (GW+letzte Node).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

RX/TX wird laut hier nicht gekreuzt (siehst Du das auch so ?):

ZitatName Pin Function
1 TXD Transmit Data Input
2 VSS Ground
3 VDD Supply Voltage
4 RXD Receive Data Output
5 VREF Reference Output Voltage
6 CANL CAN Low-Level Voltage I/O
7 CANH CAN High-Level Voltage I/O
8 RS Slope-Control Input
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ranseyer

Magst Du den Schaltplan mal inspizieren ? (unnötige Widerstände machen nix! Ich denke es müssen trotzdem welche runter damit das Routing möglich wird...)

Wenn routbar würde ich auch noch Jumper für Softserial einbauen. (Gibt es dazu schon vorgeschlagene Pins?)

Grüße

FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Den Schaltplan schaue ich demnächst gerne mal in Ruhe an, vorab mal ein Foto von meinem "Zweit-Pro-Micro-GW".
Daran ist gut zu erkennen, dass doch TX an TX und RX an RX geht (zu den lila MCP2551-Modulen hatte ich das ja bereits geschrieben und vorhin nochmal nachgesehen). Das sollte also passen, auf dem Modul messe ich je 0 Ohm von TX <-> PIN1 und RX<->PIN4 des Chips.

Was AltSoftSerial angeht, ist das beim 328p auf PIN 8 und PIN 9 festgelegt, beim Pro Micro würde ich darüber nicht diskutieren und immer HW-Serial1 verwenden... Debug ist via USB doch eigentlich immer einfacher, oder? Ansonsten wären die PINS aus der AltSoftSerial-lib auszulesen.
Code für den Pro Micro - da sind die PINs erwähnt, kommt aus dem Orginal-Sketch, behaupte ich mal:
/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* DESCRIPTION
* The RS485 Gateway prints data received from sensors on the serial link.
* The gateway accepts input on seral which will be sent out on
* the RS485 link.
*
* Wire connections (OPTIONAL):
* - Inclusion button should be connected between digital pin 3 and GND
* - RX/TX/ERR leds need to be connected between +5V (anode) and digital pin 6/5/4 with resistor 270-330R in a series
*
* LEDs (OPTIONAL):
* - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
* - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
* - ERR (red) - fast blink on error during transmission error or recieve crc error
*
* If your Arduino board has additional serial ports
* you can use to connect the RS485 module.
* Otherwise, the gateway uses AltSoftSerial to handle two serial
* links on one Arduino. Use the following pins for RS485 link
*
*  Board          Transmit  Receive   PWM Unusable
* -----          --------  -------   ------------
* Teensy 3.0 & 3.1  21        20         22
* Teensy 2.0         9        10       (none)
* Teensy++ 2.0      25         4       26, 27
* Arduino Uno        9         8         10
* Arduino Leonardo   5        13       (none)
* Arduino Mega      46        48       44, 45
* Wiring-S           5         6          4
* Sanguino          13        14         12
*
*/

// Enable debug prints to serial monitor
#define MY_DEBUG
#define   MY_SPECIAL_DEBUG

// Enable RS485 transport layer
#define MY_RS485

// Define this to enables DE-pin management on defined pin
//#define MY_RS485_DE_PIN 2

// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 19200 //57600 //9600 57600

// Enable this if RS485 is connected to a hardware serial port
//#define MY_SERIALDEVICE Serial
//#define USBCON
#define MY_RS485_HWSERIAL Serial1
//#define BOARD_ID_STR            "RS485_MySensors_ProMicro_GW"

// Enable serial gateway
#define MY_GATEWAY_SERIAL
//#define MY_DEBUGDEVICE Serial
//#define MY_SERIALDEVICE Serial2
//#define MY_REPEATER_FEATURE
//#define IMANUFACTURER Test

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  3

// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Flash leds on rx/tx/err
#define MY_DEFAULT_ERR_LED_PIN 17  // Error led pin
#define MY_DEFAULT_RX_LED_PIN  30 //5  // Receive led pin
#define MY_DEFAULT_TX_LED_PIN  17 //6  // the PCB, on board LED

#include <MySensors.h>
//#define MY_SERIALDEVICE Serial

void preHwInit() {
  wait(5000);
}

void setup()
{
  // Setup locally attached sensors
  //MY_SERIALDEVICE.println(F("Serial GW"));
}

void presentation()
{
    // Present locally attached sensors
}

void loop()
{
    //#define MY_SERIALDEVICE Serial
    /*MY_SERIALDEVICE.println(millis());
  wait(4200);
    MY_SERIALDEVICE.available();
    // Send locally attached sensor data here*/
}


Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

Alles klar, dann lass ich die Softserial Sache bleiben, das PCB ist eh schon recht voll. Ich will das nicht ohne Not ausreizen.

Schau dann doch lieber gleich das aktuelle an:
https://github.com/ranseyer/MySensors-HW/tree/master/MySensors-HM-easy-PCB-RFM-CC1101-RS485-NRF/5-GW-Sens-CAN-ProMicro
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!