Erledigt: Komische Effekte mit RS485 Gateway (War: HW Fehler)

[Ranseyer]

Ich wollte hier mal Probleme beim Wechsel eines RS485 Gateway dokumentieren um schrittweise auf die Ursache zu kommen.
Gestern hat ich das Thema schonmal.

Habe gerade ein zusätzliches GW gebaut, dieses ist auf "startup complete", und an der Seriellen Konsole (+LEDs) sehe dass dieses prächtig mit dem "Sensor" kommuniziert. Aber in FHEM klappt kein Autocreate oder ich könnte auch nicht den Sensor ansprechen bevor ich den gelöscht habe.

Den Sensor habe ich mal neu geflash mit höherer Versionsnummer das hat, wie erwartet, nichts gebracht.

Wenn ich das GW in FHEM lösche und wieder anlege würde ich erwarten dass es wieder funktioniert.
Aber diesmal funktioniert noch nicht einmal das Löschen des GW in FHEM.

Wenn ich "delete mySensGwGarage" eingebe kommt nur zurück: "connection: disconnected"

define mySensGwGarage MYSENSORS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9AD53B3-if00-port0@115200
attr mySensGwGarage autocreate 1
attr mySensGwGarage room TRX
attr mySensGwGarage stateFormat connection
attr mySensGwGarage verbose 4
define MYSENSOR_0 MYSENSORS_DEVICE 0
attr MYSENSOR_0 IODev mySensGwGarage
attr MYSENSOR_0 mode repeater
attr MYSENSOR_0 verbose 1
attr MYSENSOR_0 version 2.2.0-beta

Also werde ich das GW erst mal manuell löschen FHEM neu starten und dann wieder anlegen versuchen...

[Beta-User]

Hi Ranseyer,

vermutlich sind das keine RS485-spezifischen Probleme, sondern zwei sich überlagernde Problemkreise:

1. Das allg. Reihenfolgethema:
Löschst Du das GW, nicht aber die Node, hat die Node beim Start von FHEM noch kein IO. Dieses allgemeine Problem wurde nach meiner Kenntnis bei den MySensors-Modulen von FHEM noch nicht gelöst. Bei Interesse suche ich mal den Beitrag im Entwicklerforum dazu raus. Sollte als Fehlermeldung im log stehen nach einem FHEM-Neustart.
Ich umschiffe das Problem, indem ich auch zum Testen die GW-Definition nur ändere, nicht aber lösche. Dann bleibt die richtige Reihenfolge erhalten.
Ansonsten hilft tatsächlich nur Löschen der Node, Anlegen des GW, Neuanlage der Node.

2. Probleme von MySensors@FHEM im Umgang mit mehreren Gateways:
Nur aus dem Kopf, aber soweit ich das beobachtet habe ist das wie folgt:
Neue Nodes scheinen immer beim ersten GW angelegt zu werden (dort im IODev hinterlegt). Habe ich also eine neue RS485-Node, hat diese als IODev trotzdem erst mal das nRF-GW, bis das manuell geändert wird. Dann funktioniert auch das Senden und die Registrierung aller Children etc. problemlos.
Bitte ggf. mal testen und berichten.

Wenn es so ist, kannst Du den Titel ja ändern auf "...mit mehreren Gateways"

Gruß, Beta-User

[Ranseyer]

Mir scheint das am ehesten ein HW Problem.

Mit einer alten GW-Hardware klappt alles.
Ich habe auch nur ein einziges GW in dieser FHEM Instanz.

Ich schliesse den Thread erstmal und suche solange einen HW Fehler.

[Ranseyer]

Komische Sache:

Gateway1 (RS485) hat heute funktioniert und am Odroid Rechner einen Sensor in FHEM angelegt (immer autocreate + inclusion_mode on):

Dann habe ich Gateway1 an einen anderen Rechner gehängt und der Sensor wird dort nicht angelegt (Anderer Rechner= anderer USB Anschluss mit leicht abweichender Spannung, USB3 statt USB2)

Nach längerem herummachen habe ich Gateway1 wieder an den Odroid gehängt und den Sensor vorher gelöscht, "shutdown restart", es wird kein Sensor mehr erkannt.
onsole

(Mit MySensors 2.1 das selbe Problem!)

|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
        |___/                      2.2.0-beta

18 MCO:BGN:INIT CP=RSNNA---
26 MCO:BGN:BFR
38 TSM:INIT
38 TSF:WUR:MS=2000
40 TSM:INIT:TSP OK
43 TSM:INIT:STATID=111
45 TSF:SID:OK,ID=111
47 TSM:FPAR
65 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2041 MCO:BGN:STP
2041 !MCO:SND:NODE NOT REG
2045 !MCO:SND:NODE NOT REG
2048 !MCO:SND:NODE NOT REG
2050 !MCO:SND:NODE NOT REG
2054 !MCO:SND:NODE NOT REG
2056 !MCO:SND:NODE NOT REG
2060 !MCO:SND:NODE NOT REG
2062 !MCO:SND:NODE NOT REG
2064 MCO:BGN:INIT OK,TSP=0
2074 !TSM:FPAR:NO REPLY
2076 TSM:FPAR
2095 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4104 !TSM:FPAR:NO REPLY
4106 TSM:FPAR
4124 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6133 !TSM:FPAR:NO REPLY
6135 TSM:FPAR
6154 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:

Wenn ich am GW am seriellen Port lausche wird dort wie gestern eine Menge an RS485 Daten zu sehen sein.

Mir scheint das Problem liegt in FHEM. Aber ich habe gerade wenig Ideen wo.
(Das Gateway ist fast ganz am Anfang der FHEM.conf)

ed: Node ID manuell gesetzt:
"#define MY_NODE_ID 111"

[Ranseyer]

Es war zu 99% ein HW Fehler. (Hatte im Layout für mein erstes Test-Gateway einen Kurzschluss eingebaut, das hatte ich aber aufgrund der langen Zeit verdrängt...)

Folge: Das Gateway hatte super "Empfang", aber mit dem Senden Probleme. (Da kann man dann natürlich trotzdem viele Daten an der Debug-Schnittstelle des Gateways kommen sehen)

Drauf bin ich gekommen weil ich die Bus-Terminierung optimiert habe und dabei natürlich fleissig gemessen habe.

Diese Lösung gefällt mir super:

Terminierung um Pull-Widerständen. Zwischen A und B 150 Ohm, von A 330
Ohm nach Vcc, von B 330 Ohm nach GND. Damit wird er Bus auf HIGH
gehalten wenn alles Teilnehmer passiv sind. Und der AC-Widerstand dieser
Anordnung ist auch fast 120 Ohm (150 // (330+330)) = 122,2.

Quelle: https://www.mikrocontroller.net/topic/91581#784522