Hausautomatisierung mit Wago und Linux, wie geht es weiter?

[GLT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was bedeutet "Anwendungsklemme"

D.h. die Klemme ist zur direkten Verwendung über ein CoDeSys-Programm gedacht, was mit jedem beliebigen Controller funktioniert.
Bei Routing kann die Klemme nicht direkt im Programm als KNX-Klemme/Master verwendet werden, dies muss dann der Controller als Master erledigen u. geht somit auch nur mit einem KNX-Controller.

 

[GLT]

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.

Wenn man sich mal eingearbeitet hat, geht das mit den .yaml wirklich flott (besser als Mausschubsen).

Was hältst du eigentlich von KNX RF?
Setzt sich das durch, wird das zu nem Standard?

KNX-RF ist ein Standard
Allerdings wird dir ein bodenständiger SI das nicht als Hauptlösung planen - es ist eine gute Erweiterung/Problemlösung u. für Bestandsbauten. Aber wer Funk kennt, nimmt idR Kabel.

Fang gerade an ne Wohnung zu modernisieren und da wär das evtl. an manchen Stellen ne Überlegung.

Solange es sich vermeiden lässt, vermeide ich Medienbrüche u/o exzessiven Technologiemix.
Ich setze RF ein, wenn z.B. Mietswohnung automatisiert wird oder bei Renovierungen ein Teil des Bestandes nicht gross angefasst werden soll, aber eingebunden.

 

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Heisst aber im Umkehrschluss, dass Du per Programm auch auf die Vito schreibst u. nicht nur per Visu?

Ja sicher schreibe ich auch nach KNX: Die webvisu-Vars->SPS-Programm->889er-Master->646->TP->Vitogate-KNX

Solange Du an der Heizung ein KNX-GW dran hast, kommst Du um diesen Part nicht rum.

Die Alternative wäre Vitogate 300 (modbus), die kam erst später raus.

D.h. die Klemme ist zur direkten Verwendung über ein CoDeSys-Programm gedacht, was mit jedem beliebigen Controller funktioniert.
Bei Routing kann die Klemme nicht direkt im Programm als KNX-Klemme/Master verwendet werden, dies muss dann der Controller als Master erledigen u. geht somit auch nur mit einem KNX-Controller.

Wenn ich auf 3.5 umsteige könnte ich die 646er natürlich weiternutzen und nur die ETS-Anbindung über ein GW machen. Leider bringt mir das nicht die erhoffte Komplexitätsreduzierung und ich hätte die ETS weiter am Hals (sorry).
Nachdem meine PV ebenfalls per modbus via iob an die 889 angebunden ist, wird die Vitogate 300 immer interessanter.
Wenn nur diese Adressiererei nicht wäre (dazu hoffe ich auf blockmove und seine .xls)

Damit ist für mich die KNX-Seite ausreichend beleuchtet, danke an alle!

 

[GLT]

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)

Datenaustausch zwischen Anwendungen im Dockercontainer und PLC läuft idR unter Verwendung von Netzvariablen oder Modbus.
Beim CC100 kann man den Controller sogar rein mit NodeRed automatisieren.

 

[tomrey]

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.

Ich benutze neben Codesys ausschließlich Wago- und Oscat-Libs.

Also Neuprogrammierung:
Wie kann ich mein .pro in 3.5 nachbauen solange ich noch kein testbed habe?
Die Wago-Targets habe ich ja nur für die 2.3
Ich kann ja mein Haus nicht solange abschalten...?
Kann ich das irgendwie mit meinem raspi4 für den ich eine Codesys 3 SL runtime-Lizenz habe hinbekommen?
Wenn ich eine PFC kaufe und darauf die Neuprogrammierung zunächst ohne Klemmen mache, wie funktioniert das dann mit den modbus-Adressen ohne Steuerungskonfiguration?

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

KNX-RF ist ein Standard
Es ist eine gute Erweiterung/Problemlösung u. für Bestandsbauten.

Bestandsbau ist genau das Thema. Ich will gewisse Dinge intelligenter haben, kann aber nicht überall schlitzen und neue Kabel ziehen.
Bisher habe ich solche Dinge oft mit Homematic gelöst. Aber irgendwie ist das System tot. Sonoff, Shelly und das ganze Zeug ist mehr die Bastellösung. Focus soll sein, dass es Komponenten sind, mit denen auch ein "normaler" Elektroinstallateur im Notfall was anfangen kann.
Mit welchem Hersteller bist du bei KNX RF zufrieden? Wo stimmt Preis- Leistung? Momentan bin ich (noch) offen und hab mich für kein Schalterprogramm entschieden.

 

[Blockmove]

Ich benutze neben Codesys ausschließlich Wago- und Oscat-Libs.

Also Neuprogrammierung:
Wie kann ich mein .pro in 3.5 nachbauen solange ich noch kein testbed habe?
Die Wago-Targets habe ich ja nur für die 2.3
Ich kann ja mein Haus nicht solange abschalten...?
Kann ich das irgendwie mit meinem raspi4 für den ich eine Codesys 3 SL runtime-Lizenz habe hinbekommen?
Wenn ich eine PFC kaufe und darauf die Neuprogrammierung zunächst ohne Klemmen mache, wie funktioniert das dann mit den modbus-Adressen ohne Steuerungskonfiguration?

Bei Wago kannst du alles für die 3.5 runterladen.
Bei den Bibliotheken musst du aufpassen, da gibt es Unterschiede zwischen Wago und Original-Codesys (Raspi).
Gerade bei den intelligenten Klemmen.
Modbus verhält sich bei der 3.5 komplett anders. Da gibt es keine Verbindung mehr zu den Adressen der Karten.
Da musst du sowieso alles neu machen. Aber das ist dann wieder gleich zwischen Raspi und Wago.

 

[tomrey]

Bei Wago kannst du alles für die 3.5 runterladen.

Erledigt und installiert

Bei den Bibliotheken musst du aufpassen, da gibt es Unterschiede zwischen Wago und Original-Codesys (Raspi).
Gerade bei den intelligenten Klemmen.

Wie passe ich da auf?

Modbus verhält sich bei der 3.5 komplett anders. Da gibt es keine Verbindung mehr zu den Adressen der Karten.
Da musst du sowieso alles neu machen. Aber das ist dann wieder gleich zwischen Raspi und Wago.

Verstanden, welcher tutorial kannst du dafür empfehlen?
Bei Wago habe ich Migrationsleitfaden und Seminaraufzeichnungen für ecockpit->3.5 gefunden aber nix zu 2.3->3.5

 

[Babustino]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie passe ich da auf?

Du kannst zum Beispiel die WagoAppKNX nicht für den Raspberry verwenden, da die spezifisch für die KNX Klemme ist.
Dazu müsstest du dir für den Raspberry die KNX Lizenz von Codesys holen.

Verstanden, welcher tutorial kannst du dafür empfehlen?
Bei Wago habe ich Migrationsleitfaden und Seminaraufzeichnungen für ecockpit->3.5 gefunden aber nix zu 2.3->3.5

Tutorials findest du auf Youtube genug. Ich kann "Der Automatisierungskanal" empfehlen.

Ich würde die empfehlen das Programm neu aufzubauen, damit du V3.5 besser kennen lernst. Für die 32 Bit Version kannst du dir bei Codesys denn V2.3 Converter runter laden. Ich habe das aber nie versucht, da ich die 64 Bit Version verwende.

 

[tomrey]

Du kannst zum Beispiel die WagoAppKNX nicht für den Raspberry verwenden, da die spezifisch für die KNX Klemme ist.
Dazu müsstest du dir für den Raspberry die KNX Lizenz von Codesys holen.

Ist klar, würde ich vom Übersetzen ausschließen

Ich würde die empfehlen das Programm neu aufzubauen, damit du V3.5 besser kennen lernst.

Mache ich, danke!

 

[holgermaik]

In der WagoAppPLCModbus Doku sind Beispiele für Server & Client vorhanden.
Ansonsten bringt Codesys einen ganz guten Simulator mit zum testen.
Das Testen auf einem Raspi würde ich nicht machen. Für alle intelligenten Klemmen brauchst du die Bibliotheken von Wago.

 

[tomrey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Testen auf einem Raspi würde ich nicht machen. Für alle intelligenten Klemmen brauchst du die Bibliotheken von Wago.

Stimmt, ich habe mir das Codesys-Bundle von Wago eingerichtet und darin zum migieren eine PFC300.
Dort kann ich ja meinen aktuellen K-BUS nachbilden.
OSCAT-Bibliotheken habe ich bei Codesys gefunden, damit habe ich seinerzeit die Rollosteuerung gemacht. Allerdings habe ich aus OSCAT eine eigene lib gemacht, in die ich nur meine benutzen Bausteine extrahiert habe wegen dem 2.3er Übersetzungsvolumen.
Was ich noch kritisch sehe, ist der scheduler (Wochenzeitschaltuhr), den ich aus einem Wago 2.3er Anwendungshinweis angepasst habe. Damit mache ich u.a. die komplette ERR der FBH.

Ich will/muss wohl auch grundsätzlich über meine Variablenstrukturen nachdenken weil die Adressierung der I/Os am K-Bus, für Modbus und die Visus anders/besser sein muß. Ich hatte bisher nur lokal/global aus PRG-Sicht und DI/DO von VisuDI/VisuDO unterschieden. Für Modbus hatte ich später eine zusätzliche Merkervar-Ebene nur für die betroffenen relativ wenigen Vars eingezogen. Das geht wohl eleganter.

Jetzt sind erstmal ein paar Lerneinheiten für 3.5 dran, das handling ist ja doch sehr anders.