Hausweites Automatisierungsnetzwerk: CAN oder Ethernet?

Ich bin gerade dabei, mein Hausautomationssystem zu bauen. Als Elektroingenieur/Softwareentwickler habe ich vieles davon selbst von Grund auf neu erstellt, und ich werde hoffentlich anfangen, mehr zu bloggen und meine Geschichte und Arbeiten aufzubauen/zu veröffentlichen, sobald sie fertig sind.

Ich bin jetzt am Punkt der Lichtautomatisierung. Ich habe ungefähr 30 Wandschalter, auf denen eine Prototyp-Berührungssensor-Faceplate läuft, und ich muss diese jetzt wieder an meinen Win7 Embedded-Automatisierungscomputer anschließen. Ich muss auch ungefähr 30-40 Dimmer und Relais anschließen.

Soweit ich sehen kann, habe ich ein paar Optionen für Protokolle sowohl auf physischer als auch auf Anwendungsebene und suche wirklich nach Kommentaren oder Ratschlägen zu den folgenden Optionen, und wenn jemand andere Vorschläge hat.

Im Moment laufen alle Controller auf ARM M3-Prozessoren und ich habe sowohl Ethernet- als auch CANopen-Stacks zur Verfügung. Das System muss „Multi-Master“ sein und idealerweise sowohl ereignisgesteuert (z. B. jemand drückt eine Taste) als auch prozessgesteuert (alle 30 Sekunden einen Sensor abfragen oder einem bestimmten Knoten eine Frage stellen) unterstützen.

Öffnen können

  • Multi-Master und automatische Fehlerkorrektur/Kollisionsvermeidung
  • Prozess-, Service- und Ereignisoptionen für Nachrichten
  • Kann kompliziert sein, um das Gerät "virtuell zu verkabeln". Viel Konfiguration möglicherweise erforderlich
  • Günstig in Hardware zu implementieren, relativ skalierbar. Limit von 127 Geräten an einem Bus. Daisy-Chain-Netzwerk.

Ethernet

  • Multicast UDP oder Broadcast? Nicht sicher, was besser geeignet ist
  • Wahrscheinlich muss ich mein eigenes Messaging-Protokoll oder API oben drauf rollen, um alle Arten von Ereignissen zu verarbeiten, die ich benötige, nicht sicher über ereignisgesteuerte Aktionen
  • Star-Netzwerk, ABER könnte PoE unterstützen, was nett ist
  • Teurer in der Hardware
  • Viel erweiterbarer in der Software (möglicherweise unendlich viele Geräte usw.).

Hat jemand irgendwelche Kommentare oder Gedanken darüber, was der beste Weg ist, um fortzufahren? Ich habe das Gefühl, dass Ethernet der Weg sein könnte, aber ich mache mir Sorgen, dass viel mehr Implementierung in Software erforderlich ist.

Danke

Ich halte CAN nicht für sinnvoll, allein aufgrund der Entfernungen in einem Haus. Ich verwende gerne CAN, denke aber an die Netzwerktopologie, die Notwendigkeit der Terminierung usw. im Vergleich zum Ausführen von Cat6-Drops überall von einem Patchpanel aus, wo Sie eine große Flexibilität haben.
Ethernet. CAN ist eine Lösung für ein anderes Problem, das Sie nicht haben: hohe Zuverlässigkeit und Echtzeit. [Als Antwort auf @Krunal . Hausgroße Entfernungen sind für CAN nicht zu lang. Das Erstellen eines CAN-Busses in der Größe eines Busses ist möglich.]
Ah ja, ich bin mir bewusst, dass es theoretisch möglich ist, CAN-Busse dieser Größe zu bauen, aber nachdem ich mehrere für tatsächliche Lastwagen und Busse entworfen habe, denke ich nicht, dass es das einfachste / praktischste Design für ein Zuhause ist, wenn Ethernet verfügbar ist (unter Berücksichtigung der Leistungsminderung und anderer Probleme, die bei längeren Bussen auftreten). Aber ja, ich bezweifle, dass die Beleuchtung zu Hause sicherheitskritisch ist / Determinismus erfordert, es sei denn, SeBen ist Tony Stark.
Beachten Sie, dass Sie hier zwei Dinge mischen: Ethernet und UDP. Sie können so ziemlich alles über Ethernet ausführen, einschließlich roher Frames, wenn Sie dazu neigen (aber ich wäre wahrscheinlich nicht). UDP ist wahrscheinlich praktisch, weil es Ihnen viele Funktionen kostenlos zur Verfügung stellt, aber es gibt absolut keine Möglichkeit, das eine zu verwenden, nur weil Sie das andere verwenden.
Ein weiterer Vorteil von Ethernet ist, dass die Hardware für das Backend viel allgemeiner verfügbar ist. Von der Stange kann viel Zeit gespart werden. Wenn Sie es nur als Heimprojekt durchführen, können Sie sogar einen Ethernet-zu-Seriell-Adapter von einem Unternehmen wie Wiznet verwenden und dann einfachere Controller verwenden, um das Design zu vereinfachen.
Ein weiterer Grund für Ethernet ist die einfache Verfügbarkeit von Cat5/6 mit Plenum-Bewertung und dem gesamten Ökosystem von Hardware / Teilen / usw., das damit einhergeht, dass es eine gängige Wahl für die Heimverkabelung ist.
Gute Punkte über allgemeine Hardware, die für Ethernet besser verfügbar ist als für CAN. USB/CAN-Schnittstellen oder Intel-Chipsätze mit eingebautem CAN sind heutzutage jedoch weit verbreitet (es gibt einige kleine Motherboards mit eingebauten CAN-Schnittstellen).
Ich stimme auch nicht über Kabellängenbeschränkungen zu. CAN kann bei typischen Geschwindigkeiten, die Sie für diese Anwendung verwenden, problemlos > 1 km laufen. Ich kann das verketten. Stellen Sie sich eine Wand mit einem Gerät auf jeder Seite vor. Ich kann eine einzige Schleife zu beiden Geräten führen. Ethernet wird ein Kabel von jedem zurück zum "Knoten Null" erfordern. Da wahrscheinlich alles PoE ist, müssen viel mehr PoE-Switches/Ports verwendet werden.
@MichaelKjörling UDP war mein Gedanke, weil ich aus Gründen der Zuverlässigkeit nicht unbedingt einen "Master" im Netzwerk haben möchte. Ich stelle mir die Verwendung eines Multicast- oder Broadcast-Protokolls vor, damit alle Geräte wissen, was passiert, und auf Sensorinformationen reagieren können, ohne dass eine direkte Nachricht von einem Master-Controller erforderlich ist.

Antworten (2)

Sie könnten zwar Ethernet verwenden und einen TCP/IP-Stack auf jedem Controller implementieren und sicherlich UDP verwenden, um Sensormesswerte/Befehle/usw. zu übertragen. Ich würde den Einsatz von CAN aus folgenden Gründen empfehlen:

  1. Einfacher zu implementieren/codieren
  2. Sehr, sehr leicht. Sie können mit kleineren Controllern integrieren. Ein MCP2515 kann verwendet werden, wenn die MCU kein CAN hat.
  3. Sie könnten CAT5/CAT6 verwenden und die Ersatzdrähte verwenden und 24 V oder 36 V führen, um die Knoten mit Strom zu versorgen.
  4. Der kleine Nachrichtenrahmen kann einfach in einen Sub-1-GHz-HF-Rahmen eingebaut werden, wenn Sie sich entscheiden, den Bus über HF zu erweitern. Sie müssen nur ein CAN-zu-RF-Gateway codieren, möglicherweise mit el-cheapo RFM69-Modulen.

Es gibt einen Blog, der die Verwendung des CAN-Busses für ähnliche Zwecke untersucht, es könnte sich lohnen, ihn zu überprüfen: talk2.wisen.com.au

Wie auch immer, wenn Sie sich für Ethernet entscheiden, wäre UDP besser, sodass Sie sich nicht viel Gedanken über die Knotenadressierung machen müssen.

Alles Gute!

CAN ist viel einfacher, da es sich um eine überarbeitete RS232 / RS485-Schnittstelle handelt, die jedoch in Anzahl und Funktionen begrenzt ist. Die Verkabelung erfolgt standardmäßig seriell und ist viel einfacher als LAN. LAN und WLAN sind sicherlich viel besser, da mehr Funktionen verfügbar sind, die Preise sind natürlich höher. WLAN könnte den Vorteil haben, dass keine anderen Kabel als die Stromkabel erforderlich sind. Viele billige Schnittstellen wie die von Velleman sind mit RS485 oder CAN verbunden, aber WIFI und LAN sind viel besser, wenn Sie Ihre gesteuerten Geräte entwickeln möchten.

-1 für den ersten Satz. CAN ist weit entfernt von RS485 und noch weiter entfernt von RS232.
Hausweites Automatisierungsnetzwerk: CAN oder Ethernet?
AntwortenHierDatenschutz-Bestimmungen1y, 0v