Hausautomatisierung mit Wago und Linux, wie geht es weiter?

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi all,

nach über 10 Jahren erfolgreichen Betriebs meines Hauses mit modernen Mitteln und angeregt durch die Wago PFC300 Ankündigung, mache ich mir Gedanken über die zukünftige Weiterentwicklung meiner Lösungen.

Als ich damals vor der Entscheidung stand, war mir dieses Forum eine große Hilfe und deshalb versuche ich es nun wieder. Im Forum wird an einigen Stellen über Migrationen diskutiert aber üblicherweise nur in Bezug auf einzelne SPS. Ich habs mal durchnummeriert, dann fällt die Zuordnung der Antworten leichter.

Heutige Topologie:

1. Bedingt durch einen Heizungswechsel, bei dem ich mir von Viessmann zwangsweise KNX eingehandelt habe, mußte ich 2018 von einer 750-881 auf die 750-889 wechseln. Diese läuft seither 24/7 stabil.
2. Seit 2024 haben wir eine PV-Anlage (fronius+BYD), die ich mit iobroker, node-red, mariadb und grafana auf einem Thin Client (24/7) unter debian nutze.
3. Sonstige Aktivitäten (TV-Server, Multimedia, NAS und Backup) laufen auf einem weiteren debian-server (nicht 24/7). Hierauf gleiche SW-Konfig für PV als backup f. d. PV-Thin Client.

Alle 3 sind im LAN vernetzt, Zugang vom www nur via VPN.​

Datenaustausch mittels curl, http-GET, modbus, iobroker-adapter.​

​

Probleme/Risiken

1. Die Topologie ist komplex mit unterschiedlichen OS/Schnittstellen/tools (Ich hasse ETS!).Ich werde nicht jünger und würde gerne unnötige Komplexität in den nächsten Jahren wegmigrieren.
2. Die webvisu der 889 läuft seit dem Ende von flash auf einem eingefrorenen firefox und in der android Wago-App. Versuche die Visu auf einen Raspi 4 mit codesys 3.x/runtime SL und modbus-Kopplung zur 889 auszulagern habe ich irgendwann frustriert wegen Wago-targets, Bibliotheksproblemen und modbus-Komplexität abgebrochen.
3. Mit PV habe ich Grafana als moderne Visualisierungslösung kennengelernt aber damit habe ich 2 völlig unterschiedliche Visus an Bord.
4. Codesys 2.3 muß irgendwann nach 3.x migriert werden. Versuche mein 2.3er-Projekt auf einen Raspi 4 mit codesys 3.x/runtime SL zu migrieren, habe ich irgendwann frustriert wegen Wago-Bibliotheksproblemen abgebrochen. Ich konnte trotz 32bit Version und Converter nicht einmal mein 2.3er Projekt erfolgreich einlesen.
5. Nach win10 möchte ich auch auf den laptops auf debian umsteigen und Win-SW nur noch unter Virtualbox nutzen. Ob dann Codesys und ETS noch laufen?
6. Wago hat wohl keine KNX-Alternative zur 750-889 oder PFC mit der KNX-TP1-Klemme.

Alternativen:

1. Alternative PFC+TUX:
   750-889 und Thin Client durch PFC300 ersetzen. Dabei ist mir nicht klar, wie die Kommunikation von SW auf dem Linux-Teil (iobroker, node-red, grafana, mariadb) mit dem SPS-Teil funktioniert und ich mich evtl. weiter mit modbus plagen muß. Die PFC300 hat keine SSD. Muß ich evtl. sowieso für die mariadb einen anderen server 24/7 laufen lassen (DB auf SD ist für mich nogo). Als 99%iger GUI-Tuxer brauche ich einen desktop mit VNC f.d. Verwaltung – ob das die PFC300 kann? Kann ich im Vergleich zu heute wenigstens gleiche performance erwarten? Eine gestriges online-Seminar z. PFC300 v. Wago hat mich dabei eher verunsichert als entscheidungsrelevante Erkenntnisse gebracht.
   
   
2. Alternative SPSneu+TUX:
   889 durch eine Codesys 3.5 fähigen Controller mit separatem KNX-Router ersetzen. Damit wäre die 3.5er webvisu wieder in allen browsern nutzbar. Das gesamte Programm müsste allerdings nach 3.5 migriert bzw. neu gemacht (CFC) werden. Dabei müsste eine modbus-Alternative zur Anbindung an iobroker (Adapter?) her.
3. Alternative TUX+Feldbus:
   Die 889 auf einen reines Feldbus-Koppler reduzieren und alle „Intelligenz“, Visu usw. auf einen Linux-Server 24/7 mit Codess runtime verlagern
4. Visu-Lösung suchen unter der ich Bedienen und Beobachten (webvisu =dashboard und Grafana =Zustände/Zeitreihen) konsolidieren könnte. Keine Ahnung, ob es sowas überhaupt gibt…
5. Nix tun, ggf. 1 PC/laptop als Programmierstation unter win10 mit codesys 2.3 ohne www belassen.
6. Nicht infrage käme: Automatisierung rausschmeißen, Koppelrelais durch Stromstoßschalter ersetzen und ein gutes Buch lesen oder Spazierengehen.
   
   Ich könnte mir vorstellen, daß der eine oder andere von euch bereits weiter ist als ich oder ggf. auch schon spezifische PFC200-Erfahrungen gemacht hat oder gerne über weitere Alternativen mit diskutieren kann/möchte.
   
   Grüße

 

[Blockmove]

Die Topologie ist komplex mit unterschiedlichen OS/Schnittstellen/tools (Ich hasse ETS!).Ich werde nicht jünger und würde gerne unnötige Komplexität in den nächsten Jahren wegmigrieren.

Vor der Herausforderung stand ich auch und bin auch noch Step-by-Step dran.

Die kritische Komponente im System weder die Hardware, noch die Schnittstellen, sondern eigentlich wir.
Mit einem PFC300 kannst du zwar etliche Systeme migrieren und auf einer gemeinsamen Hardware laufen lassen, hast aber einen Single Point of Failure. Fällt die Hardware aus, steht fast alles. Fällst du aus, ist der PFC300 nicht durch jemand anders wartbar.

Ich verfolge einen anderen Ansatz:
Unterscheidung / Priorisierung der Systeme (Must-have ---> Nice-to-have) und Dezentralisierung der Systeme.

• Wago: Darauf läuft nur Beleuchtung, Jalousien und ein paar schaltbare Steckdosen.
  Der PFC100 wird demnächst auf einen PFC100 2nd. Gen. umgerüstet. eCockpit auf Codesys 3.5.
  Web-Visu ist eigenständig und einfach gehalten. Damit sollte jeder SPS'ler, der Wago kennt, zurecht kommem.
  
  
• Einzelraumregelung der Heizung
  Läuft aktuell mit Homematic. Die Heizkörperthermostate können jederzeit durch die alten Thermostatköpfe ersetzt werden.
  Zeiten und Temperaturen werden über ioBroker vorgegeben. Fällt was aus, dann bleibt eben der aktuelle Zustand erhalten.
  
  
• PV, PV-Speicher, Heizstab, Wallboxen sind alle autark lauffähig. Übergeordnet macht auch hier ioBroker Dinge wie Energieverteilung, Überschussladen, usw. Auch hier macht ein Ausfall nichts. Die Wallboxen können über die App bedient werden, Heizstab hat eine VorOrt-Bedienung.
  
  
• TV, Streaming, Multimedia
  Hier hatte ich über mehr als 15 Jahre eine Lösung mit einem zentralen Server. Im Einsatz war TVHeadend als Server und einige Raspis mit Kodi als Clients. Hat stabil funktioniert, aber erfordert viel KnowHow. Habe ich niemand im meinem Bekanntenkreis, der sich damit auskennt. Also ist das System rausgeflogen und durch Magenta-TV ersetzt worden. Kostet zwar mehr, aber ist eben Technik von der Stange mit Service und Support.
  
  
• Netzwerk
  Hier waren Komponenten von verschiedenen Herstellern verbaut. Hab ich bereinigt. Jetzt gibt es nur noch AVM und Netgear.
  
  
• ioBroker läuft als universales Gateway zwischen verschiedener Hardware, Ist für die Visualisierung, Alarmierung und Aufzeichnung zuständig. Er läuft auf einem ThinClient als Docker-Client. Ein zweiter identischer ThinClient ist im gleichen Schrank verhanden.. Fällt ioBroker aus, dann fallen zwar ein paar Konfortfunktionen weg, aber nichts "lebenswichtiges".
  
  
• Für Dokumente läuft Paperless NG auf einem Open Media Vault - Server. Die Dokumente sind als PDF gespeichert und somit jederzeit lesbar. Backup erfolgt verschlüsselt ind eine Cloud.
  
  
• Auf dem gleichen Server laufen auch noch TimeScaleDB, Grafana, Nextcloud, ... Alles in Docker-Containern. Ist mittlerweile eigentlich Standard-Technik und da habe ich einige Leute, die sich auskennen.

 

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi blockmove,
danke für den Einblick!

PFC scheint gesetzt alleine um in die 3.5er Welt zu kommen. Die Migration von 2.3 schreckt mich erheblich muß aber i.S. der Zukunftsfähigkeit und wegen webvisu wohl sein. Gibt es dazu eine empfohlene Vorgehensweise?
Welche PFC wäre zu empfehlen bzw. wie kann man z.B. anhand der heutigen Parameter die geeignete auswählen?

Bei mir kommt halt leider die KNX-Problematik wegen der Heizung dazu aber die TP1-Klemme sollte auch an PFCs laufen.
Das komplette KNX-Thema würde ich liebend gerne eher heute als morgen beerdigen aber die Fernbedienung der Heizung ist mir wichtig.
Lt. Viessmann gibt es alternativ noch ein Modbus-Gateway (das lt. Wago-Österreich sogar von Wago kommt) aber das ist nochmal ein eigener Server für viele TEURs und weitere modbus-Qual. Fernsteuerung via Viessmann-Server kommt mir genauso wenig ins Haus wie Internetzugang für BYD oder den Whirlpool.
Hier ist die Aufgabenverteilung ähnlich: Alles was im Haus gesteuert werden soll, incl. Heizstab (Überschußinfo von iobroker per modbus) und ERR (habe nur FBH, Zonen werden nur mit SW-Zeitschaltuhren gesteuert, nicht geregelt), erledigt die Wago.
Offen ist die modbus-Thematik: Wäre OPC-UA eine Alternative zur Kommunikation mit iobroker?
Habe ich das richtig verstanden: Du hast webvisu und eine iobroker-visu (welche?)? Da ich Codesys 3.x noch nicht kenne kann ich die "neue" webvisu nicht beurteilen aber die der 2.3 konnte alles was ich so brauchte und die Lernkurve habe ich schon hinter mir.

PV läuft autark, iobroker & Co. machen Doku/Visu für PV und der WAF bin sowieso ich, wenn gefragt ob schon gewaschen/gespült werden kann ;-) Grafana ist für mich entsprechend nur "Beobachten" also nice to have.
Als backup für iobroker & Co. reicht mir mein MM-Server im cold standby, evtl. packe ich meine komplette fertig konfigurierte iobroker & Co.-Lösung in eine VM wegen der Portierbarkeit. Dazu soll es spezielle tools geben um nicht 2 Systeme ständig parallel pflegen zu müssen. (Mit docker hab ich, zumindest bisher, nix am Hut, erhöht m.E. nur die Komplexität nochmal.
Das Netzwerk ist HW-seitig bereits ok (habe AVM und TP-link), SW-seitig ruht ein VLAN-Projekt um IoT-Komponenten mittels OPNsense abzuschotten.

Zu Multimedia bin ich noch im tvheadend-Modus allerdings ohne raspis.
Der tvh ist wahrlich komplex aber besser als mythtv mit dem ich mich einige Jahre vergnügt habe. Hauptproblem ist immer wieder mal die Verschlüsselung des ORF (ja wir sind mittlerweile im Süden) weil tux/tvh wegen der (legalen!) Karte zickt.
Kodi läuft überall und die Android-TV haben parallel Koax zur Schüssel - sind also bis auf den ORF auch autark.
TV ist aber nicht alles, wir haben alle Fotos und Videos der vielköpfigen Sippschaft seit vielen Jahren auf dem Server (nur debian mit samba) und schauen per Kodi auf dem beamer (TV-loses Wohnzimmer). Auch komplett nice to have, wird nach unserem Ableben obsolet.
Alle übrigen Daten kommen nach Anfall ohne weitere Verarbeitung in der (überall einheitlichen) Ordnerablage auf HD zur Ruhe. Mir reicht samba/Dateiexplorer für den Zugriff, damit spare ich mir die gesamte OMV/Clouderei.

Was meinst?
Grüße

 

[Blockmove]

Also mir reicht ein PFC100 2nd Gen. Wenn du ne sehr aufwendige Visu hast, dann evtl. nen PFC 200 2nd Gen.
OPC UA hatte ich ne Zeitlang in Verwendung mit Node RED als Gateway zu ioBroker. War damals nicht 100% stabil.
Müsste ich mal wieder probieren. Ist natürlich deutlich moderner als Modbus und einfacher im Handling.

Ja ich hab die Wago und die ioBroker Visualisierungen. Beides aber sehr einfach gehalten.
Beim Thema Visualisierung hat mich ioBroker noch nie so richtig überzeugt. Aktuell verwende ich die webui von @Jochen Kühner .
Die kommt meinen Vorstellungen ziemlich nahe. Erfordert aber deutlich mehr Einarbeitung als die vis.

Docker erhöht - meiner Meinung nach - die Komplexität nicht. Im Gegenteil!
Du kapselst Anwendungen und hast kein Theater mit Abhängigkeiten. Ich möchte es nicht mehr missen.

 

[GLT]

Die Topologie ist komplex mit unterschiedlichen OS/Schnittstellen/tools (Ich hasse ETS!).Ich werde nicht jünger und würde gerne unnötige Komplexität in den nächsten Jahren wegmigrieren.

KNX hast Du einzig u. alleine wegen Viessmann? Es ist sonst absolut nichts mit KNX realisiert ausser der 889er?

Nach win10 möchte ich auch auf den laptops auf debian umsteigen und Win-SW nur noch unter Virtualbox nutzen. Ob dann Codesys und ETS noch laufen?

In einer Win-VM läuft sowohl ETS, als auch Codesys einwandfrei - nutze ich selber so.
VB kann man machen, ist aber mit KVM eigentlich nicht nötig - am Rand erwähnt.

Wago hat wohl keine KNX-Alternative zur 750-889 oder PFC mit der KNX-TP1-Klemme.

Wie ist das Viessmann-GW angebunden - IP oder TP?
Wenn TP könntest Du auch ein normales KNX-IP-GW (aka Busschnittstelle) nutzen u. mit Node-RED (KNX-Ultimate) auf den Bus zugreifen/automatisieren - bei KNX-IP würde keine weitere Schnittstelle benötigt, das kann die KNX-Integration von NodeRed oder io.

Ich würde wohl die beiden Thin-Clients mit Proxmox ausstatten u. die vorhanden Serverinstallationen als VM migrieren (dann können alle Dienste 24/7 laufen) - der eine ist die Produktivumgebung, der andere als Backup.
Vorteil: VM kann man schnell umziehen, gut sichern, mit LXC sogar leichtgewichtig u. für Docker ist auch noch Spielraum

Visu komplett auf in den VMs installieren (nichts mehr auf Steuerungs-HW) - in deinem Falle halt eine gefällige für den iobroker (VIS z.B.)

 

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi GLT,
danke für deinen Beitrag!

KNX habe ich mir 2018 zwangsweise und ausschließlich wegen der neuen Heizung eingefangen. Zunächst hatte mich Viessmann Österreich in Richtung LON losgeschickt aber nach Vorstandseskalation hat Viessmann-D KNX vorgeschrieben und alle gekauften LON-Komponenten durch KNX ersetzt. Später kam dann noch die KNX-Anbindung einer Saunasteuerung hinzu weil der Hersteller seine eigene potenzialfreie EIN/AUS-Schnittstelle nicht zum Laufen brachte. Diese Anbindung nutzen wir in der Praxis überhaupt nicht und könnten komplett drauf verzichten.
Ansonsten ist überhaupt nichts mit KNX realisiert, ich hab ja ne SPS.

Das V-GW (Vitogate-KNX) hängt am V-LON und ist per TP an die Wago-Klemme angebunden.
Lt. Montageanleitung kann die aber auch KNX/IP.
Ich hatte damals überhaupt keine Ahnung von KNX und bin wohl einer TP-Anleitung gefolgt.
Lt. EIB.Parameter läuft die Wago-Klemme im Routermodus und lt. Wago WBM ist "KNXnet/IP-Router" aktiviert.

Hast du KNX über iobroker selbst am laufen? Das wäre dann: V-LON<->V-KNX<->KNX-Busschnittstelle<->KNX-iob-Adapter<->modbus<->PFC korrekt? Was wäre der Vorteil ggü. Wago-KNX-Klemme an einem PFC zu betreiben - die V-Daten brauche/habe ich eh in der SPS?

Exkurs: Wago-Ö hatte vor Kurzem mal rein privat erwähnt, daß das V-Modbus-GW von Wago stamme. Wer weß mehr dazu? Damit könnte ich KNX/ETS beerdigen aber nochmal ein zusätzlicher GW-Server für mehrere TEuros lässt mich zögern...

Die Virtualisierung für das Programmiergerät kommt spätestens, wenn Win10 ausläuft.
Für die iob&Co mache ich das demnächst zur Sicherheit (der mit den 2 Thin Clients war blockmove).
Warum Promox/Docker als weitere zu administrierende Zwischenebenen für VMs und nicht VMs direkt auf dem debian? Der Thin Client ist dedicated und macht nix ausser iob&Co. Habe allerdings bisher weder mit docker noch Promox gearbeitet.

Visu: Warum nicht die webvisu von Codesys 3.x auf PFC? Mir erscheint der Ansatz von blockmove mit mehreren Visus je nach Einsatzzweck vernünftig. Meine bisherige 2.3er webvisu für Bedienen und Beobachten ist inhaltlich seit Jahren ok und müsste halt nach 3.x migriert werden, die PV-Visualisierung mit Grafana ist eine reine Beobachtungs-visu auf Basis der Zeitreihen-DB.

Nochmal zur HW: Wenn ich iob&Co weiterhin außerhalb der SPS habe und keine tux auf PFC nutze, welches wäre dann der 3.xer Controller für die 750er Klemmenlandschaft? Oder ist das dann immer ein PFC?

Hast du Erfahrungen mit 2.3->3.x Migration und ggf. Tips für mich?

Grüße

 

[Blockmove]

Ich würde wohl die beiden Thin-Clients mit Proxmox ausstatten u. die vorhanden Serverinstallationen als VM migrieren (dann können alle Dienste 24/7 laufen) - der eine ist die Produktivumgebung, der andere als Backup.
Vorteil: VM kann man schnell umziehen, gut sichern, mit LXC sogar leichtgewichtig u. für Docker ist auch noch Spielraum

Proxmox hatte ich auch schon am Laufen.
Hab mich aber wieder davon verabschiedet. Empfand ich als Overkill auf nem Thin Client.
VM hab ich keine auf dem Thin Clients und Docker ist pflegeleichter und weiter verbreitet als LXC.
ioBroker, Grafana, Influx, MariaDB, Node RED, ... bekommst da alles als fertiges Docker-Image.
Dazu Docker-Compose mit Dockge ( https://github.com/louislam/dockge ) als Web-GUI und du hast quasi nen Lego-Kasten für Container.

 

[holgermaik]

Hast du Erfahrungen mit 2.3->3.x Migration und ggf. Tips für mich?

Ob eine Migration sinnvoll ist häng von den verwendeten Bibliotheken ab. Verwendest du ausschließlich Wago Bibliotheken kann es funktionieren bei Fremdbibliotheken wird es schwieriger da diese meistens auch noch geschützt sind. Alte Bibliotheken zu migrieren halte ich nicht für sinnvoll.

Solltest du dich dafür entscheiden wäre volgender Weg der beste
1. die Visu entfernen (lässt sich nicht migrieren)
2. Migration nach e!cockpit Firmware Version 22
3. Fehler beseitigen
4. Migration nach Codesys 3.5 SP18 Patch 2 (Firmware 24)
5. Migration zu aktueller Codesys Version

Meiner Meinung nach ist eine Neuprogrammierung meistens besser.
Codesys Visu: Wenn der Controller ausreichend Reserven hat spricht nichts dagegen. Allerdings ist aus der Sicht der Netzwerksicherheit eher davon abzuraten und diese lieber auf einem externen Gerät laufen zu lassen.

Da du bereits KNX hast würde ich persöhnlich diesen Weg weiter verfolgen.

OPC UA ist sicherlich das Kommunikationsprotokoll der Zukunft. Da die die neuesten Codesysversionen allerdings Zertifikate zwingend vorraussetzen ist die Umsetzung und Wartung wesentlich aufwändiger. Warum altbewärtes (Modbus) ausßschließen?

Grüße

 

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da du bereits KNX hast würde ich persöhnlich diesen Weg weiter verfolgen.

Welchen meinst du?

 

[Blockmove]

OPC UA ist sicherlich das Kommunikationsprotokoll der Zukunft. Da die die neuesten Codesysversionen allerdings Zertifikate zwingend vorraussetzen ist die Umsetzung und Wartung wesentlich aufwändiger. Warum altbewärtes (Modbus) ausßschließen?

Bei der Migration von Codesys 2.3 -> 3.5 musst du sowieso Modbus anfassen.
Das alte statische Mapping der E,A,M von 2.3 gibt es ja nicht mehr.

 

[tomrey]

Dann kann ich ja bei Neuprogrammierung modbus von vornherein berücksichtigen und nicht wie bisher nachträglich als zusätzliche Variablenebene "dranpappen".
Und schon wieder tut sich eine neue Lernkurve auf...

 

[GLT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Lt. EIB.Parameter läuft die Wago-Klemme im Routermodus und lt. Wago WBM ist "KNXnet/IP-Router" aktiviert.

Wenn Routing aktiviert ist, dann greifst Du programmatisch auf der IP-Seite auf die Datenpunkte zu.
Was läuft denn sonst noch auf der SPS bzw. sind da noch IOs im Spiel?
Was macht das Programm auf der SPS u. ist das ggfs. entbehrlich bzw. kann man das auslagern?

Hast du KNX über iobroker selbst am laufen?

Hatte.
Mit der Noderedbiblio KNX-Ultimate habe ich dann auf den Broker verzichtet u. alles in NR gemacht (Hintergrund: Ich habe eine vollständige KNX-Installation im Haus)
Aktuell bespiele ich HASS als Testinstallation.

Das wäre dann: V-LON<->V-KNX<->KNX-Busschnittstelle<->KNX-iob-Adapter<->modbus<->PFC korrekt? Was wäre der Vorteil ggü. Wago-KNX-Klemme an einem PFC zu betreiben - die V-Daten brauche/habe ich eh in der SPS?

Wäre nur so, wenn die SPS programmatisch auch noch auf IOs arbeitet - wenn die Task ausschliesslich mit KNX-Daten arbeiten, dann würde die SPS ganz entfallen können.

(der mit den 2 Thin Clients war blockmove)

my bad - ich dachte Du hättest 2 Rechner/Thinclients

Warum Promox/Docker als weitere zu administrierende Zwischenebenen für VMs und nicht VMs direkt auf dem debian?

Promox ist Debian u. natürlich kann man auch VMs direkt unter Debian laufen lassen - mit Proxmox ist das aber wesentlich komfortabler!

Visu: Warum nicht die webvisu von Codesys 3.x auf PFC? Mir erscheint der Ansatz von blockmove mit mehreren Visus je nach Einsatzzweck vernünftig.

Weil die Webvisu der PFC nie eine vollständige wird u. man somit immer mehrere Hochzeiten betanzt - nicht falsch verstehen, ich nutze die Webvisus auch, wenn diese die einzige benötigte Visu wird, ansonsten lagere ich diese stets aus.

Meine bisherige 2.3er webvisu für Bedienen und Beobachten ist inhaltlich seit Jahren ok und müsste halt nach 3.x migriert werden, die PV-Visualisierung mit Grafana ist eine reine Beobachtungs-visu auf Basis der Zeitreihen-DB.

Wenn Du die Visu auslagerst, entfällt wohl der HW-Tausch u. Du bist auch mit dem Browserproblem raus - dann kann die SPS bleiben, bis sie nicht mehr mag.
Vlt. hast Du es schon angeführt (u. ich das nur nicht richtig verstanden) - wenn die SPS nur die Heizungssteuerung anbindet und visualisiert, keine weiteren IO-Karten beteiligt sind, die per Task abgearbeitet werden, dann wäre die gesamte SPS obsolet.
Was macht die SPS alles u. welche Karten sind noch dran?

Docker ist pflegeleichter und weiter verbreitet als LXC

Docker hat mit LXC eigentlich nicht wirklich viel gemeinsam (ausser der Virtualisierung) - das eine ist reine Anwendungsvirtualisierung (Docker), das andere eine leichtgewichtiger OS-Virtualisierung (wo auch Docker drauf laufen kann).

 

[Blockmove]

@GLT
Node RED als intelligentes Gateway ist ne super Sache.
Ich hatte es auch lange für meine Kamera, Sonos und OPC UA in Verwendung.
Die Debugmöglichkeiten sind vorallem sehr einfach und nützlich.
Da bei mir das meiste über MQTT läuft, habe ich eben mit Node RED die Vorverarbeitung gemacht und dann den Datenaustausch mit ioBroker eben über MQTT. Den ioBroker Node RED Adapter hab ich nicht lange verwendet.
Mit HASS "spiele" ich auch gerade. Eigentlich ne schöne Software, aber das Scripting ist "gewöhnungsbedürftig". In Kombination mit Node RED ist's wieder ok. Bekommt halt Node RED wieder mehr Logik zum Verarbeiten.

 

[GLT]

@Blockmove
HASS hat aktuell im Bereich KNX einen ordentlichen Aufschwung, weswegen ich mich auch damit beschäftige. Man merkt schon, wo HA im Grunde herkommt, aber es entwickelt sich. Die Automatisierung im HA ist tatsächlich gewöhnungsbedürft - da war Blockly eingängiger.

Node RED ist einfach ein Allzweckwaffe u. die native Visu ist auch brauchbar, wenn man kein Visu-Fetischist ist.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

@GLT
Blockly ist wirklich ne tolle Lösung für Einsteiger und mal das kleine Script für Zwischendurch
Die meisten Scripte sind bei mir aber Javascript. Seitdem ioBroker jetzt viel auf Async umgestellt, sind auch viele der Javascript-Stolperfallen wegefallen.
HASS ist für KNX sicher ne super Ergänzung. Das Entitätenkonzept passt da ja wunderbar dazu. Gebäude, Etage, Raum ... Einmal angelegt und du hast (so vermute ich zumindest) fast fertige Visualisierung für Smartphone und Tablet.

Was hältst du eigentlich von KNX RF?
Setzt sich das durch, wird das zu nem Standard?
Fang gerade an ne Wohnung zu modernisieren und da wär das evtl. an manchen Stellen ne Überlegung.

 

[tomrey]

Wenn Routing aktiviert ist, dann greifst Du programmatisch auf der IP-Seite auf die Datenpunkte zu.

Den Unterschied habe ich nie richtig verstanden. Ich habe auf der 889 einen FbKNX_Master_889 mit dem ich die Datenpunkte via Klemme vom TP abhole. Nur die ETS greift wohl per IP via 889 auf TP zu. Oder???

Was läuft denn sonst noch auf der SPS bzw. sind da noch IOs im Spiel?
Was macht das Programm auf der SPS u. ist das ggfs. entbehrlich bzw. kann man das auslagern?

Bewahre, da läuft meine gesamte Hausautomatisierung mit DI/DO, AI drauf.
Eher wird umgekehrt ein Schuh draus indem ich KNX ersetze durch das Wago/Vitogate300 mit modbus.
Leider gibt es dazu auch beliebege Leidensgeschichten: https://forum.iobroker.net/topic/67815/viessmann-heizung-über-modbus-steuern/35

 

[Babustino]

Den Unterschied habe ich nie richtig verstanden. Ich habe auf der 889 einen FbKNX_Master_889 mit dem ich die Datenpunkte via Klemme vom TP abhole. Nur die ETS greift wohl per IP via 889 auf TP zu. Oder???

Genau. Bei einem Wechsel auf die PFC Controller würde sich das leicht ändern, da es aktuell keinen mit KNX IP gibt. Du brauchst dann auch eine IP oder USB Schnittstelle um mit der ETS auf den KNX Bus zu kommen.

 

[GLT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe auf der 889 einen FbKNX_Master_889 mit dem ich die Datenpunkte via Klemme vom TP abhole. Nur die ETS greift wohl per IP via 889 auf TP zu. Oder???

Die 646er-Klemme kommuniziert per TP mit dem Bus - wenn man die Datenpunkte per Programm als Anwendugsklemme abholt, ist der Master ein _646. Die 1.Klemme im Verbund kann man als Routing konfigurieren (bei einem KNX-Controller), d.h. die Wago-SPS funktioniert als KNX-IP-Router, dann muss man allerdings den _889-Master nehmen u. der Anwendungscontroller ist im Prinzip ein KNX-IP-Gerät (er vermittelt die Telegramme von TP auf IP u. greift dann darauf zu.
Durch diese Konstellation kann man allerdings die SPS als Programmierschnittstelle verwenden, was bei einer reinen Anwendungsklemme (ist bei allen anderen Controllern möglich) nicht funktioniert (man braucht dann eine separate Busschnittstelle für die ETS).

 

[tomrey]

wenn man die Datenpunkte per Programm als Anwendugsklemme abholt, ist der Master ein _646.

Nur zur Sicherheit: Ich hole die Datenpunkte per SPS-Programm vom Vitogate-KNX. Die 646er dient nur zum Anschluß vom TP. Was bedeutet "Anwendungsklemme" in diesem Zusammenhang? Der Rest ist klar und läuft ja auch bei mir.

 

[GLT]

Bewahre, da läuft meine gesamte Hausautomatisierung mit DI/DO, AI drauf.

Heisst aber im Umkehrschluss, dass Du per Programm auch auf die Vito schreibst u. nicht nur per Visu?
Solange Du an der Heizung ein KNX-GW dran hast, kommst Du um diesen Part nicht rum.

Beim Umstieg auf C3.5 musst Du ohnehin alles überarbeiten, da das modernere CoDeSys anders funktioniert.
Visu auslagern, KNX anders anbinden könntest Du auch schon mit dem Bestand - wäre Vorarbeit, wenn Du doch umsteingen möchtest, aber ohne Invest.

Falls Du aber jetzt tatsächlich Umrüsten willst u. dir doch eine neue PFC zulegst:
Die reine Visu könntest Du auch dort wieder realisieren, wobei Grafana&Co kannst Du auf der PFC vergessen - die Datenscchreiberei muss ohnehin anders verortet weden. Warum also nicht auf dem Rechner, wo ohnehin schon iobroker läuft, nicht auch die Visu verlagern? Die KNX-IP-Datenpunkte holst du dir über iobroker (oder NR) ins System u. die Kommunikation Visu-PFC machst Du über Modbus.