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

[frober]

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]

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]

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]

Ä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]

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]

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]

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]

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]

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]

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]

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]

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.

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]

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

Klingt plausibel

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

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

und 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]

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]

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 .