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

Begonnen von Beta-User, 22 Februar 2018, 15:14:12

Vorheriges Thema - Nächstes Thema

Beta-User

Hatte Probleme mit "Dauer-high"-Zuständen. Das passiert mit can-Bausteinen nicht.
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

pikim

#241
Das dürfte durch einzelne Busteilnehmer passiert sein, die sich mit aktivem DE-Pin aufgehängt hatten, kann das sein? CAN-Transceiver verhindern das durch einen internen Timer.

Beta-User

...ebend. Genau darum ging es ursprünglich mal...
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

pikim

Genau. Und ein anderer großer Vorteil ist, dass Kollisionen erkannt werden können, indem ständig das Gesendete mit dem Empfangenen verglichen wird. Bei richtigem CAN passiert das Bit für Bit - das geht mit UART leider nicht.

Meiner Meinung nach sollte die Kollisionerkennung aber funktionieren wenn jeder Teilnehmer, der etwas senden will, als erstes seine ID/Adresse sendet und gleichzeitig empfängt. Hat er genau das empfangen was er gesendet hat, dann ist der Bus frei und er kann die eigentlichen Daten senden. Hat er etwas anderes empfangen, dann hat gleichzeitig ein anderer Teilnehmer begonnen zu senden. Über die ID findet damit auch eine Priorisierung statt: je niedriger die ID, desto höher die Priorität des Teilnehmers. Die ID darf logischerweise nicht 2x vergeben werden.

Alles zusammen erfordert aber ein eigenes Protokoll, das diese Eigenheiten berücksichtigt. Besteht hier Bedarf oder Interesse daran? Oder baut egtl. niemand mehr kabelgebundene Sensoren/Aktoren selber?

frober

Zitat von: pikim am 12 Dezember 2021, 19:47:44
Alles zusammen erfordert aber ein eigenes Protokoll, das diese Eigenheiten berücksichtigt. Besteht hier Bedarf oder Interesse daran? Oder baut egtl. niemand mehr kabelgebundene Sensoren/Aktoren selber?
Von meiner Seite habe ich im Moment keinen Bedarf und gerade andere Projekte am laufen.
Wie es zukünftig ausschaut, man weiß ja nie. ;)

Bezgl. Protokoll, das betrifft doch eher MySensors direkt und müsste dann im Kontroller (Node/GW) verarbeitet werden und weniger auf der Fhemseite.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

pikim

Richtig. Ich habe mich jetzt auch mal bei MySensors angemeldet und dort einen FeatureRequest gestellt. Die Reihenfolge der Daten ist in MySensors auch schon brauchbar. Es fehlt egtl. nur das Rücklesen und ggf. Abbrechen des Sendens.

Ranseyer

Zitat von: pikim am 13 Dezember 2021, 19:37:02
Richtig. Ich habe mich jetzt auch mal bei MySensors angemeldet und dort einen FeatureRequest gestellt. Die Reihenfolge der Daten ist in MySensors auch schon brauchbar. Es fehlt egtl. nur das Rücklesen und ggf. Abbrechen des Sendens.


Das ist doch eine gute Sache!


(Warum mir der Ist-Stand gut genug war ? -mySensors war ja ursprünglich ein reines Funk Protokoll. Und beim Funken sind Kollisionen vollkommen normal und werden vom Protokoll ausgeregelt...)
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!

rob

@Ranseyer: Das Thema "aktive Terminierung" würde mich auch noch reizen. Hättest Du Muße das doch noch anzugehen? Oder macht das keinen Sinn mehr?

Ranseyer

Hi Rob, im Moment eher nicht...
Hast du hier krass starken Bedarf, oder warum fragst du ?
(Die Geschichte ist ja immer ein Kompromiss, und wenn es stabil läuft würde ich nichts ändern. Manchmal sind Sachen nach Verbesserung schlechter bis kaputt :-) )


Aber hier gibt es überigens zum geliebten Bus einen Sehr umfassenden und verständlichen Artikel: https://hackaday.com/2022/04/05/hacker-dictionary-rs-485-will-go-the-distance/
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!

rob

Kein starker Bedarf, eher eine Mischung aus Neugier und dem Bedürfnis es von vornherein "richtig" machen zu wollen. Basst scho :)
Aktuell habe ich das Widerstandsnetzwerk im Einsatz, ohne Einschränkungen/ Ausfälle. Ich frage, weil ich Irgendwann deutlich verlängern muss. Sollte es dann zu Problemen kommen, kann ich u.a. auf frobers Erfahrungsberichte hier zurückgreifen.
Ich hätte gemeint ein aktiver Abschluss wäre das Optimum. Danke für die Klarstellung :)

VG
rob