Fragen RS485 Gateway

Begonnen von Ranseyer, 31 Oktober 2017, 09:27:25

Vorheriges Thema - Nächstes Thema

smoudo

jetzt wirds freaky.

Als ich nachhause kam, blinkte auf den Nanos Strom und Wasser die LED "L" wie verrückt. Ein abziehen des Stroms von den nodes brachte den Bus nicht mehr zurück. Ein reset der Nodes bringt auch keine besserung - komplett strom weg auch nicht.
Nach kurzer Suche musste ich feststellen, dass das gateway nicht mehr auf "startup complete" steht sondern auf "connected"
Nach Neustart des Gateways selbes spiel. Keine Datenübertragung mehr. Kurz mal in der IDE seriell gecheckt - Kein Lebenszeichen des Gateways - was geht denn da ab?!?

smoudo

Anscheinend wird der reboot vom bootloader nicht unterstützt?!? macht zumindest die selben faxen wie wenn ich über
fhem einen reboot schicke.

Also wieder alle zurückgeflasht ohne reboot  :o

Ich habe jetzt jedem node separat ein 5V Netzteil verpasst. Wenns jetzt nicht klappt weiß ich auch nicht mehr.

Gibt es fürn Nano keinen anderen bootloader?

smoudo

Nachdem auch die separate Spannungsversorgung keine BEsserung gebracht hat, habe ich jetzt nochmal den Nano des Wasserzählers ausgetauscht - die Hoffnung stirbt zuletzt ;)

Spannung war auf 1.8V nach reset des Wasserzähler Nodes wieder im Bereich 0.3V Die beiden anderen Nodes funktionierten zu dem Zeitpunkt noch. Werde bis heute nachmittag nochmal kontrollmessungen durchführen


smoudo

Bis jetzt ist der Bus konstant auf 0,3V

smoudo

Gerade nach Hause gekommen. Um ca. 18 Uhr das letzte Signal.
Diesmal war node 1 Stromzähler der Auslöser. 1.87V auf dem Bus.
Gibt es noch Lösungsansätze? Ich hab das Eindruckl mit höherer baudrate
Kommen die Fehler zügiger.

Das komische ist, das es auch mal fast 2 Wochen durchgelaufen ist und jetzt geht gar nichts mehr.

Ranseyer

Mich würde mal die Meinung von Beta-User interessieren...

-ich hätte auf HW-Problem getippt...
-siehst Du das auch so ?

PS: An HW fällt mir ein:
-Gateway (Fake FTDI? Anderer Chip?)
-Sensor
-jeweils der Arduino
-jeweils der RS485 Chip (Fake, außerhalb der Spec, defekt)
-Versorgungs-Spannung
-Störsignale (kein Abblock-Kondensator verbaut)
-Bus (Kabel, Verbindungen, Widerstände

Das scheint mir doch recht konkret:
ZitatKein Lebenszeichen des Gateways
Würde sagen das Gateway muss immer reagieren. Egal was am Bus los war.
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!

smoudo

#111
Aufbau:

Alles arduino nano mit ch340 seriell, aus verschiedenen chargen/Lieferanten.
1x Gateway, 3x Node.
Kabel sind 4*2*0,6mm2 geschirmt, Buslänge gesamt 25-30m.
Bus hardware sind die pcb mit den max487 von dir.
Jedes node hat momentan seine eigene 5V Spannung per Netzteil. Bzw. Gateway am Intel Nuc USB.
Am Gateway ist ein 2 m Kabel mit 120 Ohm widerstand.
Hinter der letzten node sind 0,2m Kabel mit 120 Ohm zwischen A und B sowie 390 Ohm zwischen A und 5V
Und B und GND

smoudo

Die Störungen kamen bislang eher von den nodes. Gateway hatte ich jetzt einen Defekt des ch340. Der war dann zeitweise offline. Nano getauscht, seitdem läuft das Gateway sauber.

Mit keiner Reaktion war in dem Fall nur mit neuflashen zu handeln, das führe ich aber eher auf die Bastelei im sketch zurück. Wird mit der Bus Spannung eher nichts zu tun haben.

Was mir seit geraumer Zeit auch aufgefallen ist:
Ich konnte über fhem immer schön value11 setzen als korrekturwert der Stände.. Das geht auch nicht mehr, selbst wenn  der Bus frisch resetet ist.

Beta-User

Zitat von: Ranseyer am 26 Dezember 2017, 23:11:23
Mich würde mal die Meinung von Beta-User interessieren...

-ich hätte auf HW-Problem getippt...
-siehst Du das auch so ?
Insgesamt sind diese ganzen Themen sehr unübersichtlich, in meinem Fall war/ist es auch ganz sicher so, dass es nicht "die" Ursache gab oder gibt - das fing an mit Platinen, die falsch beschriftet waren und so ;) und endet bei Wacklern in der Spannungsversorgung...
Debugging ist halt recht schwierig, weil es immer eine gewisse Zeit (Stunden bis wenige Tage) dauert, bis was auffällig wird.

Aber zu smudos Themen:
- Was das GW angeht, das plötzlich auf "open" stand, klang mir das auch sehr nach einem HW-Thema. Getippt hätte ich allerdings nicht auf den USB-Wandler, sondern auf einen gelöschten Flash-Speicher des Arduinos.
- Baud-Rate: einfach testen, wenn du glaubst, niedriger wäre besser. Wie gesagt, bei mir lief es über längere Zeit @38400 auch schon ohne Probleme, teilweise haben die Arduinos SOH-count 3 und Hardware-Serial (4 Nodes+GW, die Nodes alle am selben 12V-Strang). Bis ich das wieder (wegen der 5. Node, die im Moment ein eigenes 5V-NT hat) angefaßt hatte >:( ...
- Das Ansteigen der Spannung deutet m.E. immer darauf hin, dass eine Node spinnt - interessant ist es dann aber herauszufinden, was genau eigentlich die Ursache ist. Meistens scheint es so zu sein, dass ein reset dieser Node ausreichend ist, damit alles wieder funktioniert. Aber eine richtige Regel habe ich dahinter bisher auch nicht entdecken können, es ist oft dieselbe, aber eben nicht immer. Vorgestern habe ich z.B. auch so einen Fall gehabt (SOH-gepatchte HW-serial-Node mit einer Anzahl DS18B20) und dann nur mal das Modul abgezogen. Das hat nichts geholfen (Ursache also tendenziell auf dem Arduino, nicht beim Transceiver), daher restart: War wieder da, ist aber nach sehr kurzer Zeit wieder ausgefallen. Vermutete Ursache: Spannungsversorgung. Allerdings: es ist neben dem auf dem Pro Mini verbauten 12V-Wandler ein weiterer LMS1112 (?) mit Kondensatoren (fertiges Modul) verbaut. Das dürfte eigentlich nicht so schnell in die Knie gehen.
Jedenfalls: ist die Spannung bereits deutlich weg von 0V, muß jeder Transceiver-Baustein dann richtig "arbeiten", wenn er eine "1" loswerden will (-0,2V, wie bereits hier geschrieben). Könnte also auch sein, dass da zwei Transceiver-Bausteine gegeneinander arbeiten. Ich werde jedenfalls bei nächster Gelegenheit mind. den Baustein an der neuen Node tauschen (da ist aber irgendwo auch ein Wackler an der Spannungsversorgung, das muß ich mir "bei Tag" mal genauer ansehen, oder das kommt auch an die 12V...)

- Dass das mit dem value11 nicht klappt, ist auch seltsam. An sich hätte ich behauptet, dass die Kommunikation auf dem Bus klappt oder eben nicht. Aber es könnte tatsächlich so sein, dass nur "starke" Nodes (mit genügend Spannung) gegen irrlichternde Transceiver ankommen. Es könnte sein, dass das GW (Am Pi?) zu schwach ist (aber bei ca. 0V zwischen A+B sollte es in jedem Fall gehen). Aber wenn die Info vorher nie bei der Node angekommen war, ist diese verloren, das muß dann bei "durchlässiger" Busspannung wiederholt werden.

Ansonsten bin ich mit meinem Latein auch ziemlich am Ende. Was meinen Bus angeht, bin ich am überlegen, ob ich alle Transceiver-Bausteine austausche und wenn ja, gleich gegen MAX487 (würde aber massive Lötarbeiten bedeuten, das will ich eigentlich auch nicht so richtig...). Hat jemand Info, ob die (außer der # der potentiellen Teilnehmer auch sonst besser sind)? Mischen sollte gehen, wenn nicht mehr als 32 Teilnehmer, oder?

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

Brasletti

Laut Daten Blatt von Maxim ist ein Mischbetriebder Max Chips möglich, unter der Vorraussetzung wie du schon schreibst das die Teilnehmerzalhl von 32 nicht überschritten wird.

Beta-User

Thx, dann werde ich wohl als erstes mal das GW auf Basis MAX487 angehen. (Lochraster, bin Groblöter...)

Was die Beschaltung angeht: irgendwas spezielles zu beachten? Ich würde schlicht die (reduzierte) Beschaltung der LC-Module kopieren, also 120Ohm A-B und dann an jeden Eingang 1kOhm, ggf. noch ein Kondensator für die Versorgungsspannung (Wert?). Bessere Vorschläge (ohne dass ich intensivst Schaltpläne studieren muß, die ich kaum verstehe)?

Habe dazu auch noch einen Pro Micro rumliegen (sollte auf ATMega32U4-Basis sein) . Hat mit dem jemand Erfahrung? Ich würde gerne:
- Hardware-Serial für RS485 nutzen (sollte ganz einfach gehen, indem ich serial1 für RS485 definiere)
- Dem Ding wieder eine "sprechende" USB-Kennung verpassen. Die CUL-firmware macht das ja mit diesem Prozessortyp über entsprechende defines, aber wenn ich das richtig verstanden habe, stecken diese Infos später dann im Bootloader. Klingt danach, als wäre das damit bei "normalen" Arduino-Sketches ein gesondertes Thema - was doof ist, weil ich nicht eine spezielle Board-Def erstellen will und jedes Mal aufpassen, dass ich jetzt das richtige Board einstelle oder versehentlich den "eigenen" Bootloader ganz lösche. Oder hat da jemand einen Tip? (ist prio 10, wird bis auf weiteres der einzige Pro Micro am Server sein. Es geht eher drum, einen "einsteigerfreundlichen" Weg auszuprobieren, wenn ich schon mal dabei bin).

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

Brasletti

#116
Die proMicros die ich bis jetzt verwendet habe sind in meinen NanoCuls verbaut. Die melden als "usb-busware.de_promicroCUL868-if00", scheint also als könne man denen eine eigene ID mitgeben. Probleme hatte ich beim ersten mal flashen, da hab ich dann den ganzen Bootloader weggeschossen  :P. Kann man dann aber problemlos wieder per ICSP zurückflashen. Hardware-Serial wäre bezüglich Stabilität sehr interesant.
Viele Grüße
Brasletti

Ranseyer

Zitat von: Beta-User am 28 Dezember 2017, 14:15:43
(Lochraster, bin Groblöter...)

Wenn es sauber werden soll (Stabilität), kann ich dir auch ne Platine pinseln. (Pro Micro habe ich für diesen Zweck noch nicht genutzt)

Kondensator am Eingang würde ich 4,7-100uF verbauen (=10 oder 47), parallel 22pf oder so am MAX
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: Brasletti am 28 Dezember 2017, 14:37:11
Hardware-Serial wäre bezüglich Stabilität sehr interesant.
U.a. deswegen hatte ich die damals gekauft - und eben der Option, ggf. "direkt", also ohne FTDI-Tool eine eigene ID vergeben zu können. Dass das grundsätzlich geht, ist klar, interessant ist halt, wo es reinkompiliert wird.

Das Problem mit dem Bootloader besteht darin, dass die IDE wissen muss, wie groß der ist (resp. der bereits genutzte Speicher), sonst gibt's Probleme. Das erfährt sie aus der Board-Def - die muß also zum tatsächlich verwendeten Bootloader passen, sonst braucht man wirklich den SPI-Zugang, um alles wieder in einen definierten Zustand zurückzuführen - das wäre mir dann noch zu viel, dann hat er halt den "Standard-Namen", wenn ein willkürlich gesetztes

#define BOARD_ID_STR            "RS485_MySensors_ProMicro_GW"
nicht klappen sollte...
Aber wenn, wäre das schon super easy, auch für Neueinsteiger ins Thema, zumal die ProMicros günstiger zu haben sind als gefakte FTDI-Nanos ;) .

@Ranseyer:
Danke für's Angebot. Wenn das mit HW serial und der Umbenamsung klappt würde ich sagen: Lohnt sich, da dann auch für andere interessant (vermute ich jedenfalls).
Ich bau's bei Gelegenheit auf Breadboard (habe die Lochrasterfreundliche Variante der MAX487 daliegen) auf, dann sehen wir weiter.

Ansonsten sollte ich evtl. einfach mal eine Ladung von der Hühnerfutter-Variante besorgen und schlicht die Module umlöten, geht vermutlich an dem Ende dann schneller...
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

Im MySensors Forum liest man nicht sehr viel über die Verwendung des ATMega32U4 bzw. ProMicro. Manche berichten über Probleme bei der Umschaltung der USB Schnittstelle vom Bootloader zum Eigenlichten Sketch. Evtl gibt es ja die Möglichkeit wie beim Nanocul den Bootloader komplett zu ersetzen. Eine andere Möglichkeit wäre es auch mal mit einem ESP8266 zu testen, der hat ja auch zwei Serielle Schnittstellen. bzw. halt eine übrige wenn man man einen Wemos D1 Mini zum testen verwendet.
Viele Grüße
Brasletti