Fragen RS485 Gateway

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

Vorheriges Thema - Nächstes Thema

Ranseyer

Danke für den Klasse Link.

PS: Auch das sollten wir uns noch 3-4 Mal reinziehen: https://wiki.fhem.de/wiki/HomeMatic_Wired#Der_sogenannte_Busabschluss
Finde ich nachvollziehbar.
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

Danke für den Hinweis zu HM-Wired. Das ist vor allem deswegen interessant, weil dort als Grund für die nicht-standardkonforme Ausführung des Busabschlusses genannt wird, dass die HM-wired-Datenrate _zu niedrig_ sei!

Auf MySensors war zu lesen, dass RS485 erst ab 9.600 Baud läuft - das war der Grund, warum ich dann testweise mit 38.400 Baud ins Rennen gegangen bin (und das bis heute so belassen habe, weil es jedenfalls nicht schlechter zu sein schien als 9.600).

Ergo: entweder die Datenrate runternehmen und sich für das Widerstandsthema an HM-wired orientieren (hohe Widerstandswerte bis unendlich) oder eher niedrige/standardkonforme Werte nehmen bei höherer Datenrate...

Wäre für letzteres ;)
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

smoudo

Jetzt lief das ganze schonmal besser. Seit gestern sfumktioniert die usb Durchreiche der virtuellen Maschine nicht mehr zuverlässig. Warum auch immer. Ich hoffe ein reboot erledigt das.

Frage:

Hat schonmal jemand über ein esp8266 zu rs485 Gateway nachgedacht/ realisiert?
Damit könnte man auch mehrere rs Kreise abbilden solange wlan da ist.

@ ranseyer können die Max 487 und 485 gemischt betrieben werden?

Viele Grüße

Matze

smoudo

Gateway node habe ich ausgetauscht. Scheint ein Problem mit dem usb Controller gegeben zu haben.
Seitdem ist das Gateway wieder stabil da.

Baudrate hab ich bei der Gelegenheit angehoben auf 38400 und alle nodes auf Beta 2.2.0 geflasht.


Seit 10 Uhr läuft nur noch der gaszähler, Strom und Wasser senden erneut nicht mehr.

Ratlos  >:(


Frohe Weihnachten

Matze

Beta-User

Wie sehen die Spannungen aus?


Dann: Mach mal bei allen den soh-count auf drei (letzte beta nehmen).


Kurz, da mobil
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

smoudo

#95
Spannung hab ich leider nicht gemessen im hängenden zustand ::)
Ist soh-count  ein def im rs485 Header?
#define soh-count 3

EDIT: Habs gefunden, muss heißen:

#define MY_RS485_SOH_COUNT 3

macht es sinn ein: #define MY_TRANSPORT_WAIT_READY_MS xxx mit verschiedenen werten zu setzen damit die nodes nicht gleichzeitig senden?


Grüße

Matze

Beta-User

Ja, allerdings ist die Schreibweise anders.
#define MY_RS485_SOH_COUNT 3
[/size]Letzte beta-Aktualisierung...
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

smoudo

#97
ist umgeflasht. ich werde berichten :)

komisch ist: habe eben gerade beta 2.2.0 rc 2 genommen. in FHEM steht immer noch 2.2.0 rc1 ?!?

edit: nochmal neustart - 2.2.0 rc2 - ich gehe davon aus dass das gateway beim ersten start noch nicht da war.

smoudo

Nochmal eine Verständnisfrage:

Die Usb Seite des gateways bleibt trotz erhöhen der busrate auf 115200 baud, richtig?
Zumindest kommt was brauchbares an.

Sorry für meine blöden Fragen, bin normal in einer anderen Branche unterwegs.
Aber lernwillig  ;D

Ranseyer

Korrekt !

PS: "geschlossene Fragen" wie die sind immer gut!)
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

Heute Morgen waren wieder 2 nodes tot.
Komischerweise funkte das letzte(Gas) im Bus noch während node
Strom und Wasser nichts mehr von sich gaben. Bus Spannung zwischen A und B
Ist 2V nach reset des Wasser nodes 0,2-0,3V, seitdem wieder funktionell

smoudo

Was haltet ihr von einem wdt watchdog und reboot der node?
Ist zwar nicht die Lösung des Fehlers, sollte aber zumindest die
Probleme lösen?!?

Beta-User

Das ganze ist echt mysteriös, kommt mir aber leider in Teilen nicht unbekannt vor...

Das mit dem wdt _könnte_ helfen, allerdings bin ich mir nicht so sicher, ob ein watchdog wirklich zuverlässig erkennen kann, dass die Nodes tot sind - so richtig tot sind die nämlich vermutlich gar nicht.

Zur Erläuterung: ich habe mehrere Nodes, die nicht nur Sensorik beinhalten, sondern auch autonome Rektionen - Licht einschalten bei Bewegung usw.. Selbst bei gestörter Kommunikation (also keine aktualisierten Readings mehr von diesen Nodes) reagieren diese - jedenfalls eine gewisse Zeit lang (mind. mehrere Stunden) - noch so wie sie sollen. Die loop() läuft also noch (an den interrupts hängen bei 2/3 noch Zähler, die Auswertung der Bewegungsmelder läuft innerhalb der loop()). Sowas dürfte ein wdt nicht erkennen, oder (das ist so ziemlich das einzige, das ich noch nicht ausprobiert habe ::) )?

Meine Hypothese dazu war, dass altsoftserial sich nur bedingt verträgt mit anderen libs, die timings einhalten müssen (bei den "problematischen" Nodes sind jeweils noch mehrere 1wire-Busse angeschlossen). Daher nutzen jetzt die Nodes hw-serial, die auch DS18B20 abfragen sollen. Interessanterweise trat das Problem nicht auf, solange nur eine Node dran hing, obwohl die recht viele Werte zu übermitteln hatte. Erst, als Nr. 2 und 3 dazukamen, kam es zu solchen Effekten.

Nachdem ich noch ein paar individuelle Themen an einzelnen Nodes verändert hatte und die Widerstandswerte dann tatsächlich in etwa auf das errechnete Soll geändert, hat das auch über längere Zeit gut funktioniert - bis vor 2 Wochen eine weitere Node dazu kam und der Bus zwischen Node 4 und 5 einen weiteren Teilnehmer bekam... In dem Zusammenhang  habe ich versucht, die AP-Dosen dann mal endlich zuzumachen usw.... Seitdem ist jetzt wieder der Wurm drin :( . Um was gesichertes sagen zu können, sollte ich aber den RS485-Baustein nochmal tauschen, kann sein, dass ich einen erwischt habe, der bekanntermaßen einen Hau hat (lag grad' so geschickt rum...)

So langsam werde ich dazu aber den Verdacht nicht mehr los, dass die MAX485-Module das eigentliche Problem sind. In welche Richtung, ist mir aber noch völlig unklar. Beim Verbau in die Dosen scheine ich jedenfalls auch Spannungsprobleme bei deren Versorgung verursacht zu haben.

Fragen:
- gibt es Anhaltspunkte für die Annahme, dass die MAX485-Teile isoliert mit einer Art overflow den Dienst einstellen?
- @Matze:
-- Kannst du die Module separat abziehen bzw. stromlos machen? (das habe ich bisher auch noch nicht versucht). Es wäre interessant zu wissen, ob die Kommunikation wieder läuft, ohne dass man den Arduino selbst neu anwirft.
-- Kannst du auch  mal zwischendurch messen? Ich hatte den Eindruck, dass die A-B-Spannungswerte teilweise über Stunden kontinuierlich anwachsen können, bis dann schließlich die 2V erreicht sind und - außer beim Verursacher (?) nichts mehr geht.

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

smoudo

Jepp kann ich machen. Hab das ganze auch in AP Dosen, mit Wago Klemmen. Hab jetzt mal den Wachhund mit rein genommen. Bin mal auf die Wechselwirkungen gespannt. Die besagte altsoftlib, ist die standardmäßig in Verwendung? Bei mir laufen die nodes auf max487. Die Frage ist wie spannungsempfindöich sind die Teile? Hab vor die nodes ein 47uf geschraubt -ohne Erfolg-
Wenn das jetzt nicht läuft Test ich mal mit 3 separaten Stromkreisen.

Hast du die Standarte 485 auf dem pcb? Hab noch 5 davon da, falls du bedarf hast?
Sind die mischbar?!?

smoudo

Ging schneller als erwartet, kurzer Check- alle nodes ohne readings :(