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

frober · 02 April 2021, 20:54:35

Zitat von: KarlHeinz2000 am 02 April 2021, 20:48:58
Den Buffer RX/TX musst du direkt in der hwserial.cpp (?) im arduino Ordner ändern. Im sketch geht das nicht. Schadet auf jeden Fall nicht. RAM ist beim GW kein Problem.
Bin leider nicht vor Ort und kann den Pfad nicht raussuchen.
Mit SOH habe ich noch nicht gespielt.

Ähhm, GW läuft mit Softserial (Nano)

Beim Testen mit kurzen Leitungen hatte ich die Probleme nicht. Da waren die Sensormessungen alle paar Sekunden.

Beta-User · 02 April 2021, 20:57:19

Auf dem GW kann man die Zahl der gepufferten Nachrichten irgendwie erhöhen, ist aber kompliziert, soweit ich mich entsinne.

SOH würde ich erst mal auf das GW beschränken.

Ansonsten habe ich den Start der Arduinos entzerrt, die warten alle unterschiedlich lang, bis sie versuchen, sich ins Netz einzubuchen...

frober · 02 April 2021, 21:02:54

Zitat von: Beta-User am 02 April 2021, 20:57:19
Auf dem GW kann man die Zahl der gepufferten Nachrichten irgendwie erhöhen, ist aber kompliziert, soweit ich mich entsinne.

SOH würde ich erst mal auf das GW beschränken.

Ansonsten habe ich den Start der Arduinos entzerrt, die warten alle unterschiedlich lang, bis sie versuchen, sich ins Netz einzubuchen...

OK, danke.

KarlHeinz2000 · 02 April 2021, 23:51:55

Zitat von: frober am 02 April 2021, 20:54:35
Ähhm, GW läuft mit Softserial (Nano)

Bei mir auch. Der USB link läuft aber über Hardware serial. Da hilft es, damit der Rx Buffer nicht überläuft. In die 64 Byte Standard Buffer passen w/c 1,5 Nachrichten. Bei meinem Baud-Unterschied von >1:10 konnte ich von fhem aus max 3 lange Nachrichten direkt nacheinander senden bis zum Überlauf. Hängt auch etwas an der fhem Performance. Mit 256 Byte Buffer komme ich gut klar. Die Grenzen hab ich noch nicht getestet.

frober · 03 April 2021, 08:09:05

Danke euch beiden.

Ich werde beides umsetzen, ich denke das ist der richtige Weg. Mal sehen, ob ich heute noch dazu komme...

Seit gestern ca. 16 Uhr läuft die Kommunikation, ohne Eingriff (senden aus Fhem) stabil.

frober · 03 April 2021, 19:14:43

Wenn ich das so sehe, müsste ich es doch auch im Sketch definieren können!?

HardwareSerial.h

Code Auswählen

#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 64
#endif

GW mit neuen Einstellungen geflasht, mal gespannt wie weit ich ihn nun stressen kann bevor der Bus wieder abstürzt.

KarlHeinz2000 · 03 April 2021, 19:26:13

Zitat von: frober am 03 April 2021, 19:14:43
Wenn ich das so sehe, müsste ich es doch auch im Sketch definieren können!?

Geht leider nicht.
Schau dir mal den benutzten RAM nach dem compile an, da sieht man es...
Irgendwie kann man in einem extra Tab precompiler Optionen definieren. Damit müsste es gehen. Ich weiß aber nicht wie

frober · 05 April 2021, 12:57:23

Der Bus läuft stabil, solange ich von Fhem keine Befehle sende, Abläufe starte.
Läuft sogar mit nur einem Endwiderstand (120 Ohm) problemlos.

TX und RX Buffer von 256 und SOH 3 am GW hat bisher nichts gebracht.
Bei fast allen Nodes habe ich nun SOH 3 und nach jedem send/recieve ein wait(100) (Ausnahme die Node direkt am GW ist unverändert, da diese nur Sensordaten sendet und das bisher problemlos).
Auch habe ich die Starts der Nodes über ein wait am Anfang von presentation entzerrt.

Sobald mehrere Nachrichten nacheinander, trotz wait(100) gesendet werden bleibt der Bus meist hängen.
Nach einem reboot des GW läuft wieder alles.

Z.B. lasse ich meine Relais zeitgesteuert laufen. Das Setzen von percentage und danach Schalten des Relais ist ok. Nach Ablauf der Zeit sendet die Nodes "Relais off" und nach wait(100) "percentage 0" und das kommt schon nicht mehr an, der Bus hängt. Genauso schalte ich 2 Relais nacheinander über eine andere Node, Relais1 off, Relais2 on mit wait(100). Die 2. Nachricht kommt auch nicht an, Bus hängt.

Beim send des Relaisstatus ist ACK aktiviert und es wird auch der erfolgreiche Empfang kontrolliert und evt. neu gesendet (3x nach je 1s).

Davor hatte ich wait von 20 bzw. 40, kein Unterschied

Wie weit kann/soll ich noch erhöhen, falls das überhaut noch eine Auswirkung hat?
Im MySensor-Forum hat einer geschrieben, dass es immer ein wait(150) setzt, allerdings war das mit Radio.

frober · 05 April 2021, 20:32:41

Neue Erkenntnisse: das hängt sehr wahrscheinlich beim send mit der ACK-Anforderung.
Ist hier Fhem zu "langsam", zu viele Daten in kurzer Zeit?

Beim "manuellen" Bodenfeuchte messen funktioniert alles, von Anfang an, ohne Absturz.
Ich setzte aus Fhem V_LOCK_STATUS auf on, Feuchte wird gemessen, gesendet und V_LOCK_STATUS wieder auf aus gesetzt. Alles ohne ACK.

Eigentlich kommt doch nur die gleiche Nachricht mit ACK vom Empfänger (Fhem oder GW?) zurück und wird per receive empfangen. Dauert das alles so lange, dass der Bus ab und an abstürzt?

Hmm, ich wollte eigentlich sicher gehen, dass alles zuverlässig funktioniert.
Schaltet von euch jemand Relais incl. Rückmeldung (Zeitschaltung o.ä.) zuverlässig?

Nachtrag:
ACK kann nicht (nur) der Auslöser sein. Die Node mit den 2 Relais nacheinander hat kein ACK beim send und trotzdem die gleichen Probleme.

frober · 06 April 2021, 19:08:25

Ich habe nun aktiv mal mit dem Schalten den Relais gespielt. Der Bus oder das GW ist jedes mal abgestürzt.

Logauszug:

Code Auswählen


2021.04.05 10:15:08 1: ERROR: addToWritebuffer for WEB_192.168.20.102_59000 without FD
2021.04.05 10:15:08 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:705 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.05 12:12:05 1: RMDIR: ./restoreDir/save/2021-04-02
2021.04.05 12:14:30 1: ERROR: addToWritebuffer for WEB_192.168.20.102_59204 without FD
2021.04.05 12:14:30 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.05 12:14:47 1: ERROR: addToWritebuffer for WEB_192.168.20.102_59204 without FD
2021.04.05 12:14:47 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
.
.
.
2021.04.06 18:43:13 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:43:13 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:418 MYSENSORS::DEVICE::__ANON__:3379 HandleTimeout:695
2021.04.06 18:43:48 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:43:48 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:418 MYSENSORS::DEVICE::__ANON__:3379 HandleTimeout:695
2021.04.06 18:45:13 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:45:13 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:418 MYSENSORS::DEVICE::__ANON__:3379 HandleTimeout:695
2021.04.06 18:45:24 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65529 without FD
2021.04.06 18:45:24 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:418 MYSENSORS::DEVICE::__ANON__:3379 HandleTimeout:695
2021.04.06 18:46:20 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:46:20 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.06 18:46:34 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65519 without FD
2021.04.06 18:46:34 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.06 18:46:55 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65487 without FD
2021.04.06 18:46:55 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773
2021.04.06 18:47:02 1: ERROR: addToWritebuffer for WEB_192.168.20.6_65487 without FD
2021.04.06 18:47:02 1: callstack: addToWritebuffer:731 FW_addToWritebuffer:761 FW_AsyncOutput:3847 CallFn:2023 asyncOutput:966 MYSENSORS::DEVICE::onInternalMessage:748 MYSENSORS::onInternalMsg:614 MYSENSORS::Read:3847 CallFn:773

Die Webaddr ist der PC oder Laptop, von dem ich gesteuert habe.
Was bedeuten die Meldungen von MySensors?

Vereinzelt finde ich auch weiter Logs:

Code Auswählen


2021.04.05 19:47:39 3: MYSENSORS: ignoring internal-msg from unknown radioId 1, childId 255 for I_DISCOVER_RESPONSE

2021.04.05 19:48:32 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_MYSENSORS_DEVICE.pm line 794.

FVERSION 10_MYSENSORS_DEVICE.pm:0.237770/2021-02-20

Beta-User · 06 April 2021, 21:33:02

Hmm, also der erste Teil kommt eigentlich aus FHEMWEB. Da werden gets abgesetzt, aber bis die Antworten kommen, gibt's die aufrufende FHEMWEB-Seite nicht mehr. Sieht insgesamt irgendwie verbogen aus.

Die Meldung "ignoring internal-msg from" kommt jedenfalls nur, wenn GW und Node irgendwie nicht zusammenpassen, sei es, dass das IODev falsch ist, sei es, dass irgendwelche NodeID's erfunden würden oder sowas in die Richtung. Falls du mehrere GW's hast, kannst du ja als erstes mal checken, ob es da Überschneidungen gibt. Allen voran bei der Node 1.

frober · 06 April 2021, 22:19:51

Zitat von: Beta-User am 06 April 2021, 21:33:02
Hmm, also der erste Teil kommt eigentlich aus FHEMWEB. Da werden gets abgesetzt, aber bis die Antworten kommen, gibt's die aufrufende FHEMWEB-Seite nicht mehr. Sieht insgesamt irgendwie verbogen aus.

OK, das könnte ich, mit reload der Seite, verursacht haben, wenn vom heartbeat keine Antwort kam. Werde ich nochmal überprüfen.

Zitat
Die Meldung "ignoring internal-msg from" kommt jedenfalls nur, wenn GW und Node irgendwie nicht zusammenpassen, sei es, dass das IODev falsch ist, sei es, dass irgendwelche NodeID's erfunden würden oder sowas in die Richtung. Falls du mehrere GW's hast, kannst du ja als erstes mal checken, ob es da Überschneidungen gibt. Allen voran bei der Node 1.

Ich habe nur einen GW und den mit RS485.
NodeIDs erfunden, hmm, fehlerhafte Daten auf dem Bus?

Kann das mit den Abstürzen zutun haben und wie kann ich es am besten debuggen?
Kann ich in Fhem den Datenverkehr mit loggen?
Wobei ich wahrscheinlich besser auf dem Bus mit lese, aber wie, zw. Arduino und CAN?

Irgendwie habe ich das Gefühl, das das Aufhängen des Buses nicht von Kollisionen verursacht wird.
Das manuellen Anstoßen der Feuchtemessung dauert keine Sekunde bis alle Nachrichten da sind, ohne Absturz.
Das Schalten der Relais funktioniert fast nie ohne Hänger

Am Sketch kann es eigentlich nicht hängen. Test hat funktioniert und der Bus hângt meist direkt nach dem Absetzen des Befehls aus Fhem.
In wenigen Fällen hat es aber schon funktioniert.

Beta-User · 07 April 2021, 09:20:34

Zitat von: frober am 06 April 2021, 22:19:51
OK, das könnte ich, mit reload der Seite, verursacht haben, wenn vom heartbeat keine Antwort kam. Werde ich nochmal überprüfen.

Klingt plausibel

ZitatIch habe nur einen GW und den mit RS485.
NodeIDs erfunden, hmm, fehlerhafte Daten auf dem Bus?

Dann sollte es zumindest kein GW-Zuordnungsproblem geben. Kaputte Daten könnte sein, aber vom Bauchgefühl her steckt da eher was anderes dahinter. Die Nodes haben alle eine manuell vergebene ID?

ZitatKann das mit den Abstürzen zutun haben

Woran machst du fest, dass der Bus "abgestürzt" ist? Nach meinem Verständnis hieße das, dass irgendwas den Bus auf "Dauer-high" zieht (>ca. 2.5V) , was aber eigentlich durch die CAN-Bausteine nie dauerhaft der Fall sein sollte. Wenn das doch passiert, stimmt m.E. irgendwas an der Verkabelung nicht und/oder mind. einer der Bausteine ist kaputt.
Falls einer der Bausteine es nicht schafft, "gute" Daten auf den Bus zu schreiben, könnte es evtl. an der Stromversorgung liegen (bin da aber nicht vertieft drin, ist eher Bauchgefühl).

Zitatund wie kann ich es am besten debuggen? [...]

Die Daten direkt auf dem Bus oder hinter dem CAN-Baustein abzugreifen, ist wenig aufschlussreich, das ist "Kauderwelsch" (soweit ich mich entsinne, hatte ich mal einen Seriell-USB-Wandler hinter einen MCP2551 geklemmt). Was aber gehen sollte, ist eine Repeater-Node mit auf den Bus zu hängen, da sollte dann alles via USB ausgegeben werden, was so an Daten über den Bus geht - ganz ähnlich wie bei Funk.

Falls du die Option hast, das GW gegen eines mit Hardware-Serial zu tauschen, würde ich das mal angehen.

frober · 07 April 2021, 09:59:14

Problem gelöst

Eigentlich darf ich es nicht verraten, sonst werde ich verhauen

(man sollte auf Beta-User hören

)
Problem ist, wenn im Test alles funktioniert, dann denkt man im produktiven Einsatz nicht soweit...

Im GW hatte ich Relais definiert, die ich nur selten schalte. Daher dachte ich, das macht keine Probleme, da es den GW nicht belastet/blockiert.
Anscheinend kommt dieser damit aber nicht klar, wenn Relais auf den Nodes geschaltet werden. Irgendwas hängt dann.
Letzte Erkenntnis war, dass nichts "abstürzt", er reichte das USB-Kabel zum Raspi kurz abzuziehen und die Kommunikation läuft wieder. Kein reboot etc.

Da von diesen Relais nur eins in Gebrauch war, werde ich dies anders an Fhem anbinden, mal schauen...

Danke für eure Unterstützung.

Und nun "duck und weg"

Beta-User · 07 April 2021, 10:13:20

So ganz verstanden habe ich das Problem bzw. die Lösung noch nicht. Ich habe auch einige Relais bzw. SSR's an diversen Nodes im Einsatz... Die Versorgung dieser Nodes ist aber über die zentrale 12V-Strecke, so dass ausreichend Saft da sein sollte, um die jeweils zu schalten, ohne die Kommunikation in den Abgrund zu ziehen...

Ansonsten freut es mich ja sehr, wenn man auf mich hört, aber ich weiß (leider, zum Glück, ...) auch nicht alles

.