SLSS CANopen Analyser

  • Entwicklungsstand: in Entwicklung (letzte Aktualisierung: 08.12.2022)
  • Veröffentlichungen: (Python-Offline veröffentlicht / C# Live Analyser ausstehend)

 

Vorgeschichte

Mit meiner CAN Bus-Software SLSS CANAnalyser* schein ich doch bei so einigen CAN Interessierten einen Nerv getroffen zu haben.
Durch den kostenlosen Download und den „cheap’n’open hardware“ Ansatz habe ich mittlerweile einige nette Kontakte knüpfen können (sogar weltweit was ich immer noch Wahnsinn finde).

Da meine beruflichen „Wurzeln“ bis Anfang letzten Jahres eigentlich immer fest im Automotive Sektor verankert waren, war für mich bis dahin das Multi-Master-Prinzip und die unabhängige Botschaftszuordnung stets das was den CAN Bus ausmachte und wofür ich Ihn einsetzte. Diese grundsätzliche Auslegung findet man zum Beispiel auch in den Beschreibungen der CAN Übertragungsverfahren*, wie hier zum Beispiel auf Wikipedia!

Im Zuge eines Jobwechsels wurde ich dann im ersten Projekt jedoch gleich mit dem Thema CANopen* konfrontiert.
Das Wort „CANopen“ war mir zwar bekannt und bis dahin auch schon einige Male an diversen Stellen „untergekommen“, doch war ich immer weit genug entfernt um mich nicht tiefer mit dem Thema beschäftigen und auseinandersetzen zu müssen!
Da mein neuer Projektleiter jedoch eher die Einstellung „learning by doing“ vertritt (was ich sehr an Ihm mag) und in unserer Abteilung noch kein Wissen hinsichtlich CANopen vorhanden war, wurde ich gleich ins kalte Wasser geworfen und musste mich mit den „Eigenheiten“ des CANopen Protokolls vertraut machen.
Schnell stellte ich fest, dass der CAN Bus selbst und der Aufbau der darauf versendeten Botschaften (CAN Frames) immer noch dasselbe war, doch altbekannte Dinge wie das Multi-Master-Prinzip mittendrinnen obsolet und durch mir bis dahin unbekannte Sachen wie Guarding, Heart-Beat, Node-IDs, SDOs, PDOs oder das ominöse Objektverzeichnis (object dictionary) ersetzt worden waren! So musste ich selbst erst einmal lernen was CANopen überhaupt ausmacht, welche Vorteile und evtl. auch Nachteile der Einsatz von CANopen mit sich bringt und wie die Daten auf dem Bus zu interpretieren sind.

Mehr lesen

Python UDP-Communication Class

Vorgeschichte

2020 kam ein Freund auf mich zu und fragte mich, ob es nicht irgendwie möglich wäre seine smarte Haustürklingel in die von ihm installierte Hausautomatisierung zu integrieren. Beim Betätigen der Klingel sollte ein Bediendisplay aus dem Bildschirmschoner in den Anzeigemodus wechseln und so das Videobild der in der Klingelanlage verbauten Kamera angezeigt werden, ohne das man vorher auf den Bildschirm klicken muss. Da die eingesetzte Hausautomatisierungslösung auf CentOS aufgesetzt war, brauchte er eine Schnittstellenlösung welche dort leicht zu implementieren war. Damit war damals bereits der Grundstein für die Python UDP-Communication Class gelegt.

 

Warum UDP Kommunikation

Auf diese Frage gibt es eine ganz einfache Antwort: Die Klingel stellte nur die Möglichkeit, ein UDP-Datagramm an einen vorkonfigurierbaren Port zu senden, bereit. Das gezielte Erhalten einer Botschaft via TCP gab es schlichtweg nicht. Damit war die Auswahl auf UDP beschränkt und die Umsetzung bereits festgelegt.

Mehr lesen

Alexa-Skill für den Raspberry Pi mit Python

Vorgeschichte

Als Erweiterung für meine DIY-Hausautomatisierung* hatte ich schon längere Zeit den Wunsch, verschiedene Geräte auch per Sprachsteuerung ansprechen und steuern zu können. Da bei uns die Amazon Echo-Dots mittlerweile auch in fast jedem Raum Einzug gehalten haben, war die meiner Meinung nach perfekte Hardware eigentlich schon vorhanden. In meiner Vorstellung musste ich es daher „nur“ hinbekommen, dass die von Amazon übersetzten Sprachbefehle an meine Hausautomatisierung weitergeleitet und anschließend von mir per Script ausgewertet werden. Leider ist dies nicht ganz so einfach umzusetzen wie ich es mir gedacht habe.

Mehr lesen