RS485 basierend auf Arduino ProMicro; gesplittet von:Fragen RS485 Gateway

Begonnen von Beta-User, 30 Dezember 2017, 13:14:56

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Brasletti am 31 Dezember 2017, 11:18:08
Sieht eigentlich gar nicht schelcht aus ;) !
Die Rückseite habe ich euch mit Absicht vorenthalten ;D , aber es sieht besser aus als mein LC-Modul-GW auf Nano-Basis, das sind nur ein paar Drähte und die zwei Boards...

Was Alternativen angeht: An sich geht es m.E. nur um das GW - und dafür wäre das Thema Stromverbrauch im sleep() zweitrangig. Dann kämen  auch die günstigsten STM32F106-Boards in Frage, die kosten knapp über 2 Euro und sind auf allen gängigen Marktplätzen verfügbar (habe noch keine Erfahrung mit Ali). Zumindest theoretisch könnte man damit sogar mehrere serielle Schnittstellen@USB aufmachen, aber das ist eine andere Baustelle.

Aber ganz allgemein nochmal: An sich war nach meiner bisherigen Erfahrung (und meiner ersten Annahmen dazu) das GW (trotz AltSoftSerial) nicht das wirkliche Problem, sondern eher die normalen Nodes bzw. die Wechselwirkungen zwischen diesen. Hätte nur nicht geschadet, das auch noch ausschließen zu können.
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

Hier übrigens meine erste Sicht auf das Thema: https://github.com/ranseyer/MySensors-HW/blob/master/Experimental/GW-Sens-RS485-ProMicro/board.png
(Der Schaltplan bleibt so chaotisch bis klar ist ob/welchen Sinn das Thema macht)

PS: Habe es dann mal bei Pin3 für Interupt gelassen.
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!

KarlHeinz2000

An den ProMicros als RS485 GW habe ich mir damals die Zähne ausgebissen. Das geht irgendwie nicht  >:(
siehe: https://forum.mysensors.org/topic/5336/gateway-using-atmega32u4

Schlussendlich machen die auch keinen Sinn. Ist halt quasi der UART-USB Chip schon mit im AVR drin. Dafür braucht man aber ggfs spezielle Treiber und hat die Probleme beim flashen. Dann lieber einen normalen ProMini/Nano mit FTDI o.ä. nehmen und RS485 über AltSoftSerial.

Habe seit >1 Jahr einen Nano mit AltSoftSerial am laufen - ist sehr stabil, ohne jegliche Probleme.

Beta-User

Hallo Karlheinz2000,

Danke für die Rückmeldung, den Thread hatte ich dann auch gefunden und überlegt, ob ich mal nachhaken soll, ob du es doch noch hinbekommen hattest.

Auch, wenn es hier etwas OT ist:
Kannst du (hier oder ggf. im allg. RS485-GW-Fragen-Thread) kurz beschreiben, wie dein Netzwerk derzeit aussieht? Die Anzahl nodes, Spannungsversorgung zentral @5/12V, Baudrate, #Children und Sendehäufigkeit wäre z.B. interessant.

Ansonsten finde ich den ProMicro an sich nicht mehr soooo problematisch (außer, dass er als RS485-GW scheinbar (?,s.u.) nicht will). Man muß halt wissen, dass man den Reset durchführen muß kurz vor dem Start des Upload-Vorgangs. Treiberthemen hatte ich bislang keine, nutze aber auch nur Ubuntu und Debian, die erkennen das Teil ohne weiteres.

AlsSoftSerial hat so seine Tücken, habe dazu noch das hier https://forum.mysensors.org/topic/5051/rs485-stress-test und das hier gefunden: https://github.com/mysensors/MySensors/issues/954, es wäre also schon besser, wenn man das auf "einfachem" Weg loswürde...

(OT: Ich hatte etwas Mühe bei meinen ersten Versuchen mit den STM32F106-Boards, die mußte ich erst entsperren, um den "Melbourne"-Bootloader draufzubringen, das ist m.E. für Einsteiger eine deutlich größere Hürde als der Hinweis, dass man zum richtigen Zeitpunkt den Reset machen muß...)

Zurück zum ProMicro: Auch, wenn er sich nach dem Starten anders verhält als ein Nano (keine Serial-Printouts des MySensors-Headers, kein "Startup complete"), bin ich zwischenzeitlich nicht mehr so ganz sicher, ob das nicht doch läuft. Vielleicht ist der Startvorgang schlicht zu schnell abgeschlossen oder irgendwas in der Art. Wenn ich in die loop() MY_SERIALDEVICE.print-Anweisungen reinbaue, dann kommt dort raus, was hingehört. Vielleicht habe ich auch nur einen Fehler beim Verkabeln gemacht ::) . Werde das bei Gelegenheit nochmal testen, das kann aber wieder dauern.

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

KarlHeinz2000

#19
Ich habe RS485 nur genutzt, da ich an der Haustür ein Mysensors Display haben wollte und im Blechkasten der Klingelanlage nur schlechter Funkempfang war. Dafür waren in der Klingelleitung noch 2 Adern frei :-)

Mein RS485 Setup:
GW: Nano via USB an RPi und weiter via Ser2Net an RPi2 mit FHEM
Node 1: Display mit Mega2560
Node 2: TempSensor mit ProMini
RS485 Baud: 9600
Serial Baud: 115200
Spannungsversorgung dezentral 5V, GW über USB
Kabel-Länge ca. 15m
120 Ohm am GW und Node1

Der TempSensor sendet im Minutentakt, das Display bekommt ab und zu mal Daten, dann aber auch mal 10..15 Msgs hintereinander (so schnell wie FHEM ist)

Mit den Baudraten hatte ich viel rumgespielt, da ich anfangs Probleme mit verloren gegangenen Msgs hatte.
1. Problem war aber, dass der Mega2560 Bilder von SD Karte gelesen hatte und in der Zeit ankommende Msgs nicht verarbeitet hatte (RX Bufferüberlauf). Nachdem ich den RX Buffer vergrößert hatte lief in Richtung Display alles.
2. Vom Display Richtung FHEM sollte man nicht zu schnell senden. FHEM bekommt nicht alles mit. Ich habe mir die Kommunikation angeschaut: Am GW kommt auf USB Seite noch alles raus, Ser2Net überträgt auch alles, aber FHEM empfängt nicht alles. Einige 10ms Pause zwischen den Msgs hilft...

Zwischenzeitlich hatte ich auch einen Mega2560 als GW dran, da lief das GW mit 2 HW Serials. Quasi gleicher Sketch wie auf dem ProMicro. Nur kam aus dem ProMicro nie was raus...
Mag sein, dass bei viel Traffic AltSoftSerial überfordert ist, ich habe ja ein übersichtliches Setup.

Beta-User

Danke erst mal.

Schade, dass du auch verlorene Messages hattest, klingt wirklich danach, als träten Probleme wirklich vermehrt mit steigender Datenmenge auf (habe auch teilweise 10+ Werte auf einen Rutsch, teilweise auch Delays eingebaut, aber eigentlich den Eindruck, dass das geht, wenn die Kommunikation insgeamt passt).

Sind das MAX485-Chips bzw. Module oder "was besseres"?

Die Feststellung, dass sich FHEM ggf. verschluckt, ist interessant, ebenso, dass der Mega mit 2 HW-Serials ging (oder habe ich das falsch verstanden? Irgendwo hatte ich mal was gelesen, dass mit dem größeren Mega auch jemand Probleme gehabt haben soll)...
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

Brasletti


Beta-User

[ist hier eigentlich OT, oder?]
Ja, bzw. auf allen bis auf GW+letzte Node (an der sind dann die 20k-Widerstände gg. 440-er ersetzt). Auch R5+6 (?) sind überall weg bis auf die am GW.

Ich habe zwischenzeitlich die zentrale 12V-Spannungsversorgung in Verdacht. Spannungsmäßig hängen GW am hp, Node 4 an einem eigenen 5V-Netzteil und der Rest an dem 12V-NT).
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

Brasletti

[Nochmal OT ;)]
So wie ich das verstanden habe, hättest du R5 und R6 drauf lassen können. Hier https://arduino-info.wikispaces.com/RS485-Modules schön dargestellt.

Beta-User

[Immer noch OT ;D ]
Interessante Seite!
Dass die recht hohen "Seitenwiderstände" ziemlich egal sind, war mir klar, da war ja was mit 1/R1=1/R2+1/R2 usw.. Da ich aber schon mal dabei war wollte ich einen wirklich (weitgehend) der Norm entsprechenden Bus...
Mein Augenmerk liegt jetzt aber auch auf den anderen 4 Widerständen: da DE/RE verbunden sind, ist dort der effektive Widerstand niedriger, und die Werte werde ich auch nochmal kontrollieren (nur 1k verbaut?). Vielleicht kommen die Arduinos gerade dann aus dem Tritt, wenn sie wegen häufiger Sendeversuche dort einen undefinierten Zustand vorfinden (Spekulier, spekulier...).

Seltsam ist übrigens bei den Modulen auch, dass meine Messungen zuverlässig andere Widerstandswerte für einen der beiden 20k (R5/6) auswerfen: nur 10k.

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

KarlHeinz2000

@Beta-User:
- ja, habe normale MAX485 drauf
- ja, mit dem MEGA lief das GW mit 2x HW Serial problemlos
- das FHEM Daten verschluckt hat ist mit einem RPi1 passiert. Habe upgrade auf RPi2 gemacht. Das bringt ja ordentlich Performance. Vielleicht ist das jetzt besser....

Hast du R5/6 in der Schaltung gemessen? Entweder sind beide messtechnsich parallel, oder es sind wirklich 10k verbaut. Im link sind im Schaltplan 20k gezeichnet, aber auf der oberen Platine 10k bestückt...

Beta-User

Da ich eben gemerkt habe, dass ich das hier noch nicht kundgetan habe:

Mein 2.3.0-alpha-GW läuft jetzt bereits seit einiger Zeit als Kombi aus ProMicro und MCP2551 auf einer China-Platine, die ursprünglich einen TJA-irgendwas drauf hatte; der MCP2551 ist angeschlossen an Serial1 (also HW-Serial) mit 19200 Baud.
Wenn Interesse besteht, poste ich den Sketch dazu, aber da war eigentlich nicht besonderes einzustellen...Ungewohnt ist halt, dass der MySensors-typische "Startbildschirm" in der Regel nicht zu sehen ist, weil der Start schon durch ist, bis die Kommunikation mit der seriellen Schnittstelle des Rechners paßt (oder irgend so was halt; kann sein, dass ein wait(200) oder so in before() hilft, um dem zu begegnen, allerdings muß man beachten, dass uU. der serielle Monitor der IDE auf den richtigen Port zeigt - flashen und gleichzeitig den seriellen Monitor offen halten war @Linux kontraproduktiv, soweit ich mich entsinne).

EDIT: Den code für das GW habe ich hier gepostet, das angesprochene Warten ist in preHwInit(). Der code selbst enthält noch einiges an auskommentierten Versuchen, die man getrost löschen kann ::) . Bei Gelegenheit und Interesse liefere ich gerne eine "aufgeräumte" Version nach.
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