(Web)Abfrage für dez. Lüfter

[makki]

Hallo,

bevor ich mich nun an die Umsetzung gehe, wollte ich kurz meine Gedanken zwecks Anregungen teilen

Problemstellung: 8 dez. Lüfter (Meltem M-WRG) mit Wärmerückgewinnung, sind via RS-485 & Moxa im LAN erreichbar und mit einem einfachen ASCII-Protokoll komplett ausles- und steuerbar. Soweit alles paletti, Steuerungs funktioniert auch schon aber ich kann aber aus (noch ) unerfindlichen Gründen nur einen Wert pro Abfrage setzen/lesen, sonst kommt Datenmüll zurück, aber das sei erstmal egal..
Bedienung der Lüfter soll ausschliesslich via HS(-Logik) erfolgen, d.h. man kann davon ausgehen dass Werte nicht "von aussen" verändert werden.

Zum (regelmässigen) Schreiben/Aktualisieren gibt es 4 Werte (Lüftungsstufe 0-10, Querlüftung aktiv, Abluft-stufe 0-10 und Zuluft-Stufe 0-10)
Zum Abfragen gibt es jene 4 (kommt jeweils als Antwort beim setzen), Wahlschalterstellung, Frostgefahr, Filterzustand, 4xTemperatur (Abluft innen, nach Wärmetauscher, Zuluft aussen, nach Wärmetauscher sowie 2xLuftfeuchte (innen und aussen nach WT).

Die Kernfrage die mich jetzt quält ist wie ich es genau mache, stabil, smart und bei möglichst wenig Aufwand versteht sich

Variante 1, der Holzhammer - gefällt mir irgendwie nicht wirklich:
- Je Lüfter&Wert eine "Web"abfrage, senden der vier Einstellungen und Abfragen der 9 Statuswerte + jeweils in iKO schreiben. Ginge zwar aber irgendwie eine Menge getipse und geklicke für 112 Abfragen; das Problem der gleichzeitigkeit könnte man vielleicht mit entsprechenden Verzögerungen der Startzeitpunkte vermeiden (Systemstart -> Verzögerung -> Telegrammgenerator oder so).

Variante 2:
- Jeweils eine Webafrage für zu setzende und je eine Abfrage für zu lesende Werte, Steuerung welcher Lüfter/Wert angesprochen wird über die Logik (Zieladresse/Wert in ein iKO per Befehl setzen, Abfrage starten, bei Änderung der empfangenen Werte wiederum via Logik dem entsprechenden Ziel-iKO zuordnen)
Das getipse verlagert sich in den GLE, wie man die gleichzeitige Ausführung verhindert (vor allem bei den Antworten zwecks Zuordnung relevant) bin ich noch unschlüssig, ebenso bestehen starke Zweifel daran ob sich um die eleganteste Methode handelt
Die Screenshots unten beziehen sich auf diese Idee..
Variante 2a wäre die jeweiligs zu lesenden/schreibenden Werte auch noch in iKOs zu setzen, womit es nur noch zwei Webabfragen wären. Das Problem des endlosen getippes bleibt..

Probleme die ich dabei sehe: Paralell laufende Webafragen sollten möglichst vermieden werden; die Moxa kann max. 4 Verbindungen und was dabei rauskommt wenn mehrere die alle auf den RS485 einbügeln ist mehr als fraglich..

Makki

[makki]

Ok, ich versuchs mal anders
Könnte dieselbe Webafragen mehrfach quasi gleichzeitig ausgeführt werden oder kann ich davon ausgehen dass der HS das sequentiell mit einer Verzögerung von sagen wir mal mind. 500ms abarbeitet ?

Um das besser in der Logik darzustellen bin ich mittlerweile auf was gestossen: Auswahlschalter.. (es gibt ja sooo viele Bausteine..)

Makki

[makki]

Ich unterhalte mich mal weiter mit mir selbst
Das Thema ist gelöst, ich habe mir jetzt einen sep. Logikbaustein für Steuerung und Auslesen der Lüfter geschrieben, kann ich bei Interesse gerne mal dokumentieren und reinstellen.
Es hätte sich zwar auch mit vorhandenen irgendwie lösen lassen, das wäre mir aber viel zuviel geklicke geworden..
Für das Problem mit den gleichzeitigen Abfragen hab ich mir die Queue aus dem HSRuss-Projekt abgeschaut.

Makki

[marc.keynejad]

Au Mann, was ist da denn schiefgegangen, so schlimm war die Anfrage doch gar nicht.

Also was Du da vorhast hört sich nicht so richtig trivial an, deshalb solltest Du Deine grundlegenden Strukturen asynchron auslegen. Dazu
1. Programmier-Regel: "Behellige niemanden (kein Modul) mit Dingen, die Ihn/Es nix angehen". Will heißen es ist immer besser zu kapseln und Dinge
von den Routinen durchführen zu lassen die dafür gemacht sind.
Konkret, Kommunikation zu Deinen Lüftern in ein Modul auslagern und die Regelung in ein anderes.
2. Regel: Schnittstellen klar definieren. Wenn Du über iKO kommunizierst hast Du einiges an Freiheitsgraden, dabei geht neben der Übersicht auch mal die Typsicherheit flöten. Das Fehlersuchen dabei ist die wahre Wonne.
3. Regel: Kommunikation zw. den Modulen klar definieren und Handshaken.
Nach Systemstart/Wertänderung etc. rotes Licht von den Kommunikationsmodulen, bis alle Werte zuverlässig sind. Die Regler dürfen darauf gerne warten.
4. Regel: Versuche die Module zu recyclen und wieder zu verwenden(das spricht für die GLE-lastige Variante).
5. Regel: Mach den Kram nicht mit dem HS, sonst musst Du bei jedem Mal überprogrammieren auf den geeigneten Zeitpunkt warten.

[makki]

Marc, so ganz kann ich grad nicht folgen Ich vermute mal das bezieht sich jetzt primär auf den ersten Post ..
Sieht jetzt jedenfalls etwas anders aus, ich hatte da zu Beginn in der Tat ein paar verquere Gedanken.. Ich dachte zu Beginn, das ganze durch zusammenbauen der entsprechenden Abfragestrings im GLE mittels vorhandenen Bausteinen zu lösen aber da hätte ich mindestens 40 Blätter machen müssen..

Der Baustein (quasi Nummer 1) ist zwar sicher nicht perfekt (man braucht ja auch noch Ziele) aber funktioniert bisher einwandfrei und zusammen mit der Queue dürfte es auch keine Probleme geben.. Screenshot und Baustein anbei..
Was dabei noch fehlt ist direkte Kontrolle ob der abgesetzte Wert auch angenommen wurde, das kann man im Moment nur dem pro Lüfter ausgegebenen Statustext entnehmen..
Trivial wars nicht aber auch nicht unlösbar und für Verbesserungvorschläge bin ich natürlich immer offen

Makki

[marc.keynejad]

Jupp, hauptsächlich der erste Post, der vermuten liess, dass es an allgemeinen Grundlagen fehlt.
Schön, dass Du es jetzt am Start hast, wenn's funzt, prima.