Timberwolf Server - Docker - Was habt ihr damit vor

[Cepheus73]

Hast Du denn schon bestellt (sorry, ich habe keine Liste für Klarnamen zu Forennick)? Wenn ja, was für wann?

Kein Problem. Ja, einen 2400. Hab ich seit Weihnachten ;-)

[StefanW]

Hui. Mit 30 kann ich nicht dienen, sondern nur mit 7, aber beim Test bin ich auch gerne mit dabei, jetzt wird es für mich wieder spannend!

Hast Du denn schon bestellt (sorry, ich habe keine Liste für Klarnamen zu Forennick)? Wenn ja, was für wann?

lg

Stefan

[StefanW]

Hallo Micha,

Zählt da auch der Logikprozessor dazu? Das wäre für mich das wichtigste Plugin.

wenn sich jemand findet, den Logikprozessor als Plugin im Docker auf dem Timberwolf Server zu testen, kann er das gerne tun.

Ich denke nicht, dass die Mehrheit der Kunden es gut fände, wenn ich deren Budget (Kaufpreis / Timberwolf Care) dafür verwende, ein spezielles Plugin offiziell zu prüfen und zu supporten, dass nur von einer Minderheit von geschätzt 2 % der Kunden eingesetzt wird.

Da geben wir das Geld doch lieber dafür aus, die Logikengine des Timberwolf Servers so fit zu machen, dass damit alles abgebildet werden kann, was der Logikprozessor konnte, damit man diesen komplett ersetzen kann. Nicht weil der Logikprozessor schlecht wäre, aber die Investition in eine künftige Entwicklung für die nächsten 10 bis 20 Jahre sinnvoller ist.

lg

Stefan

[mivola]

Wir haben einen Betatester gewinnen können, der 30 Plugins im Einsatz hat. Lasst uns das mal testen und dann werden wir sehen, was heraus kommt.

Zählt da auch der Logikprozessor dazu? Das wäre für mich das wichtigste Plugin.

Danke und VG
Micha

[luigi4711]

+1 für einen Asterisk / SIP Server. Habe meinen Router auf eine OPNSense Firewall umgebaut, aber mir fehlt zum Abschalten der alten Fritzbox noch etwas, dass die Telefonie abdeckt. Ich habe zwar parallel einen größeren Proxmox Host laufen, aber da ich dort öfter Dinge ändere, weiß ich nicht, ob ich damit die nötige Verfügbarkeit für Telefonie erreiche. Da ein Asterisk ja (einmal eingerichtet), wenig Änderung bedarf, wäre ein Container auf dem Hausautomations-server eine gute Idee.

[Cepheus73]

Ab der Beta 7 liefern wir die Docker-Umgebung aus und vermutlich dann auch schon die Plugin-Container. Wir haben einen Betatester gewinnen können, der 30 Plugins im Einsatz hat. Lasst uns das mal testen und dann werden wir sehen, was heraus kommt.

Hui. Mit 30 kann ich nicht dienen, sondern nur mit 7, aber beim Test bin ich auch gerne mit dabei, jetzt wird es für mich wieder spannend!

[StefanW]

Ich hoffe aber, dass ihr die WG-plugins irgendwie in einen Docker bekommt, ohne dass man 1 Docker je plugin braucht! Das wäre bei 50 Plugins ein Problem...

Ja, das ist kein Problem, mehrere Plugin im selben Docker ist kein Problem (nach bisherigen Tests) und wir haben auch kein Limit gesetzt. Das Limit sind die Ressourcen.

Wir haben selbst keine Plugins im Einsatz, daher können wir das selbst nur wenig testen. Daher freuen wir uns über jede Hilfe.


lg

Stefan

[StefanW]

Das wird so nicht funktionieren, denn die "alte Software" wäre dann ja eine Wiregate-Installation. Du meinst vermutlich mit der "alten" Schnittstelle. Es hängt immer davon ab, was das Plugin genau benutzt. Wenn es die halb-offiziellen Funktionen sind, dann wäre das vermutlich noch machbar. Schwierig wird es, wenn irgendetwas undokumentiertes oder tief ins Wiregate reingreifende benutzt wird.
Du musst bedenken, dass die Architektur drumrum ja komplett anders ist.

Schon sehr richtig.

Was wir machen ist, dass wir einen Image liefern, mit dem man einen Container erstellen kann, der die alte WireGate Umgebung für Plugins emuliert. Also mit einem Pers-Scriipt dass als abgespeckter wiregated fungiert. Mit Standard-Plugins die nur auf den eibd zugreifen sollte das funktionieren.

Ab der Beta 7 liefern wir die Docker-Umgebung aus und vermutlich dann auch schon die Plugin-Container. Wir haben einen Betatester gewinnen können, der 30 Plugins im Einsatz hat. Lasst uns das mal testen und dann werden wir sehen, was heraus kommt.

lg

Stefan

[SirTom]

Es hängt immer davon ab, was das Plugin genau benutzt. Wenn es die halb-offiziellen Funktionen sind, dann wäre das vermutlich noch machbar. Schwierig wird es, wenn irgendetwas undokumentiertes oder tief ins Wiregate reingreifende benutzt wird.

Kann mir denn jemand im Vorfeld sagen, welche Plugins laufen werden und welche nicht?

[Cepheus73]

Wird da einmal ein Docker von euch mit der alten Software zur Verfügung gestellt

Das wird so nicht funktionieren, denn die "alte Software" wäre dann ja eine Wiregate-Installation. Du meinst vermutlich mit der "alten" Schnittstelle.
Es hängt immer davon ab, was das Plugin genau benutzt. Wenn es die halb-offiziellen Funktionen sind, dann wäre das vermutlich noch machbar. Schwierig wird es, wenn irgendetwas undokumentiertes oder tief ins Wiregate reingreifende benutzt wird.
Du musst bedenken, dass die Architektur drumrum ja komplett anders ist.

[SirTom]

Hallo,
mich würde interessieren, inwieweit im Docker eine Nutzung der bestehenden Plugins möglich ist. Wird da einmal ein Docker von euch mit der alten Software zur Verfügung gestellt oder wird die Nutzung der verwendeten Plugins gar direkt auf dem TW möglich sein?

[Cepheus73]

Generell: Kann ich in einem Docker Container eine neue Schnittstelle implementieren?

Ja, wenn die Schnittstelle IP-basiert ist (und die Ports nicht schon vom TW selber verwendet werden), auf jeden Fall. Du kannst im Container ganz genauso Daemons laufen lassen oder Clients.
Ist in der IT mittlerweile gang und gäbe, dass Applikationen per fertigem Docker-Container ausgeliefert werden. Einfach starten und fertig.

[Edward]

Ist es möglich, einen Docker mit Modbus RTU auf dem TW 2500 laufen zu lassen? Ich würde damit gerne meine Heizung steuern, die Modbus RTU als Protokoll hat.
Generell: Kann ich in einem Docker Container eine neue Schnittstelle implementieren?

[gbglace]

Zur Erweiterung der Liste:

Ansprechen der Heizungsanlage von Viessman im Docker und Integration in gute Heizungssteuerung auf TW-Server.
der vcontrold scheint da das Stichwort zu sein.

Nutzung der Helios KWL über die RS485-Schnittstellen oder IP.

Für EDOMI gibt es da ja schon eine Integration beider Systeme. Da ich keiner echten Programmiersprache mächtig bin beobachte ich einfach wo die einfachste Bedienbarkeit gegeben ist.

StefanW arbeitet Ihr bei Elabnet noch an dem Projekt einer prädiktiven Heizungssteuerung? Da ich bei mir im Haus in der Sanierung auf flinke Heizkörper gesetzt habe und sehr viel Abwesenheiten im Haus sind und Gasbrennwert neben Solarthermie und Kamin mit Wasseranschluss betreibe sehe ich da Nutzungspotential. Von daher fände ich da eine Integration in eine TW Logik vorteilhaft.

[starwarsfan]

Hallo Peter

Bei mir gibt es auch Interesse für EDOMI im Docker-Container.

Was ich bis jetzt verstanden habe ist, daß es von Seiten der CPU-Architektur in den Desktopmodellen gehen sollte. Eine weitere Bedingung für EDOMI ist jedoch CentOs 6.x, das wäre doch bei den Desktopmodellen anders; also würde EDOMI dort nicht laufen,oder mißverstehe ich da etwas?

Ja, missverstehst Du.

Es kommt lediglich auf die CPU-Architektur an. Diese muss übereinstimmen und das ist bei den Desktop-Modellen gegeben, da das vorhandene Docker-Image ebenfalls auf x86_64 basiert. Damit ist dieses Image auf jedem Docker-Host lauffähig, welcher auf x86_64 basiert. Welches OS der Host verwendet, spielt dabei keine Rolle.

Ein Problem sind die 950er/960er TW's, da diese auf ARM in 32Bit basieren und es dafür kein CentOS6-Image gibt.