[wiregate] Timberwolf Server Auswahl

[knatti]

Ich bin gerade beim entscheiden welcher Server für mich der Beste wäre (Bestand ersetzen)

Verwendung:

• derzeit genutzt: Schnittstelle zu KNX (Programmierung, Temp von Schaltern)
• derzeit genutzt: Ethernet (Admin, Auswertung ansehen)
• derzeit genutzt: 3 1-Wire Linien per USB Koppler (2 im Haus, 1 im Garten)
• geplant: CAN-Bus (Heizung auslesen, Lüftung steuern)
• geplant: evtl. paar KNX logiken

Möglichkeiten:

Server 350
Hat so weit ich sehe alle gewünschte Schnittstellen.
Daten Auswertung (Grafana) müsste ich dann selber betreiben oder?

Server 2600
Hat auch CAN-BUS, und kann wohl dann auch „alles“


Soweit richtig oder gibt es andere Möglichkeiten?

[irgendwer]

Die Frage wird sein, inwieweit man auf den CAN Bus zugreifen kann. Auf das eigentliche OS soll es ja keinen Zugriff mehr habe ich gelesen. Ob sich der CAN Bus dann in einen Docker Container durchreichen lässt? Hier müssen wir wohl auf weitere Berichte von StefanW warten. Ich lese meine Rotex WP gerade per https://github.com/zanac/pyHPSU mit einem Raspi aus und bin grundsätzlich interessiert das über das neue WG zu integrieren. Ist aber schon ein etwas spezieller Fall, auch da es keine Standard Schnittstelle ist.

[knatti]

Danke für die Infos:
Mein Wärmepumpe ist von MECO und steuert derzeit die Lüftung (Renovent Excellent).
Ich würde aber gern die Lüftung etwas komfortabler steuern. WP würde ich nur auslesen falls möglich.
Für Loxone haben die was entwickelt, also nehme ich an dass es auch mit anderen Geräten möglich ist. Notfalls kann ich mich auch bei der Firma melden oder vorbeifahren falls ich Infos brauche.

Also noch Abwarten was kommt und Plan B mit raspberry pi.

[SirTom]

Also für einige Stiebel Eltron Geräte funktioniert sowas schon mittels eines usb2can-Adapters:
https://knx-user-forum.de/forum/supp...04-404-can-bus

[StefanW]

Hallo,

Server 350; Hat so weit ich sehe alle gewünschte Schnittstellen.

Richtig (und der 950 auch)

Daten Auswertung (Grafana) müsste ich dann selber betreiben oder?

Ja.

Den Grafana Server können wir darauf nicht mehr installieren (nach heutigem Stand). Für die Installation des Grafana-Server - soweit man diesen haben möchte - kann jeder andere Linux- oder Windows-Rechner verwendet werden. Grafana ist durchaus verzichtbar, das Admin Tool bietet auch out-of-the Box grafische Auswertungen der Zeitreihen. Mit Grafana ist es eben nur sehr viel schöner und bietet deutlich mehr Optionen für die Auswertung.

Server 2600. Hat auch CAN-BUS, und kann wohl dann auch „alles“

Richtig. Da fehlt dann gar nicht mehr, fast alles an Schnittstellen (bis auf 1-Wire), lokale USV, doppelte Spannungsversorgung, Massenspeicher und Power ohne Ende.

Soweit richtig oder gibt es andere Möglichkeiten?

Nein, ich sehe keine anderen Möglichkeiten, sind aber durchaus drei Varainten.


lg

Stefan

[StefanW]

Hallo

Die Frage wird sein, inwieweit man auf den CAN Bus zugreifen kann. Auf das eigentliche OS soll es ja keinen Zugriff mehr habe ich gelesen.

Richtig, eine gute Frage.

Zugriff auf das OS braucht man auch nicht mehr, weil man mit Docker sehr viel mehr Freiheiten hat. Dort kann man sich auch einen Container mit Mint oder Ubuntu installieren und innerhalb des Containers mit seiner Lieblings-Distro arbeiten, ohne am Hauptsystem etwas zu stören, weil man sich damit in einer geschützten Sandbox befindet.

Ob sich der CAN Bus dann in einen Docker Container durchreichen lässt? Hier müssen wir wohl auf weitere Berichte von StefanW warten.

Theorie: In Linux wird der CAN-Bus wie ein (Ethernet)-Interface behandelt Dies geht via SocketCAN. Durch das Interface-Konzept können mehrere Anwendungen auf den CAN-Bus zugreifen. Mit der --net=host Option sollte man aus Docker den SocketCAN adressieren können.

Ob das in der Praxis so funktioniert, müssen wir noch testen.

Ich lese meine Rotex WP gerade per https://github.com/zanac/pyHPSU mit einem Raspi aus und bin grundsätzlich interessiert das über das neue WG zu integrieren. Ist aber schon ein etwas spezieller Fall, auch da es keine Standard Schnittstelle ist.

Wenn wir soweit sind, in einigen Monaten, können wir daran gemeinsam testen. Melde Dich dann einfach nochmal bitte


lg

Stefan

[DiMa]

Theorie: In Linux wird der CAN-Bus wie ein (Ethernet)-Interface behandelt Dies geht via SocketCAN. Durch das Interface-Konzept können mehrere Anwendungen auf den CAN-Bus zugreifen. Mit der --net=host Option sollte man aus Docker den SocketCAN adressieren können.

Ob das in der Praxis so funktioniert, müssen wir noch testen.

In der Praxis funktioniert das so ohne weiteres nicht - ob das für den geplanten Einsatzzweck eine Rolle spielt, ist aber eine andere Frage.

Dem Socket ist es zwar egal, wieviele Clients zugreifen und wenn die nur zuhören, geht das auch gut, aber in dem Moment, wo mehrere Clients schreibend zugreifen hat das ein hohes Fehlerpotential, da CAN im Gegensatz zu "echten" Netzwerkprotokollen keine ernstzunehmende Transport- und LLC-Schicht hat. Im Automotive-Bereich wird daher ein irrsinniger Aufwand betrieben, irgendwie fest- und sicherzustellen, ob/wann/wie eine Nachricht übertragen wurde - da würd' ich aber nicht bei jedem CAN-Device 'drauf wetten.

D.h. in der Praxis muss man eine transport/business-Logik dazwischen bauen. Im einfachsten Fall (und wenn Latenzen keine Rolle spielen) z.B. MQTT oder (besser) AMQPP. Das dürfte auch für den Häuslebauer die einfachste Lösung sein.

Rein technisch hat ein Docker-Container erst mal auf alle Netzwerkschnittstellen Zugriff, wenn entsprechend konfiguriert - und damit auch auf CAN am TW-Server, wenn Elabnet das wie angedeutet mit SocketCAN realisiert. das dürfte die Frage des OP gewesen sein.

Für eine Häuslebauer-Installation wird man aber vmtl. diese Baustellen gar nicht haben, da die übertragenen CAN-Bus-Nachrichten eher übersichtlich und mit endlicher Frequenz übertragen werden dürften (ist geraten, hab' kein einziges CAN-Bus-Gerät im Haus - kann mir aber irgendwie nicht vorstellen, dass jemand für 'ne Heizung oder so Fast-CAN oder CAN FD implementiert (und dann auch noch nutzt)). Praktisch wird man aber als Normalsterblicher wie auch für die KNX-Bus-Nachrichten einen Handler brauchen, der sich um so einen Krams kümmert - schliesslich greifen auch smarthome.py, Callidomus, OpenHAB, Wiregate usw. nicht direkt auf den Bus zu (z.B. über das BCU SDK), sondern haben z.B. einen eibd oder knxd dazwischen, der sich um so einen Kram wie "Tunnel", "KNX-Routing", Übersetzung in IP-Multicast usw. kümmert. Soweit ich weiss hat nur Christian in Edomi tatsächlich selber den ganzen Buszugriff implementiert. Oder man nutzt eben ein echtes CAN-IP-Interface, so dass der Zugriff komplett über IP (also die network sockets) erfolgen kann. Vielleicht setzt sich ja Elabnet mit PEAK zusammen - die können das 'rauf und 'runter

Natürlich könnte der TW-Server auch ein CAN-IP-Interface sein/werden - aber so wie sich das liest, dürfte das zumindest bis auf Weiteres nicht ganz weit oben im Backlog stehen

Eigentlich sind das auch alles Fragen, die für den TW-Server an sich irrelevant sind (da wäre eher interessant, welche HW für das CAN-I/f verbaut wird) - das sind eigentlich Applikationsfragen. Gibt es eigentlich eine Logik-Engine/Visu, die CAN direkt unterstützt? Ansonsten ist eh' Selbermachen angesagt. Hier gibts einen guten Einstieg.