Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Vielen Dank für die Unterstützung. Werde ich doch gleich mal umsetzen.
Könnte mir schon vorstellen, dass Deine Hilfestellung sicherlich so manchen unter uns an spricht. sollte man ggf. mal überlegen in die Makros mit einzupflegen.
// Steuerung Rollo OG bei Frost
FreigabeRollo=AUS
if systemstart() then read("Helligkeit.Süd-1/0/22"); \\
read("Außentemperatur-1/0/14") endif
if after(systemstart(),5000u64) then FreigabeRollo=EIN endif
//und dann
Runter=("Außentemperatur-1/0/14"<1.0) and ("Helligkeit.Süd-1/0/22"<8.0) and (FreigabeRollo)
if Runter then write("%Pos.anfahren Rollo Essen Ost OG-3/2/105",65%); \\
write("%Pos.anfahren Rollo Essen Süd OG-3/2/115",65%); \\
write("%Pos.anfahren Rollo Essen West OG-3/2/125",65%) endif
Zeit=AUS
if wtime(08,30,00,WOCHENENDE) then Zeit=EIN endif
if wtime(05,30,00,WERKTAGS) then Zeit=EIN endif
Hoch=("Helligkeit.Süd-1/0/22">200.0) and Zeit
if Hoch then write("%Pos.anfahren Rollo Essen Ost OG-3/2/105",0%); \\
write("%Pos.anfahren Rollo Essen Süd OG-3/2/115",0%); \\
write("%Pos.anfahren Rollo Essen West OG-3/2/125",0%); \\
Zeit=AUS endif
Das hat was mit strukturierter Programmierung und Determinismus zu tun.
Also: 'Ich lege erst los, wenn ich sicher bin, dass ich alle Informationen habe' und 'Ich mülle den Code nicht mit totem Code zu, den ich nur 1x beim Systemstart benötige'.
Das mag verrückt klingen, aber das ist einfacher als 50x im Code die Systemstart()-Funktion mit 50 Variablen und entsprechend vielen Abfragen, Balkonen und Deklarationen (die ja nur 1x ausgeführt werden) zu verwenden.
Oder mit anderen Worten: Es könnte so einfach sein ...
Ps. Und ich habe nicht gesagt, dass die Systemstart()-Funktion nicht sein darf!
Das hat was mit strukturierter Programmierung und Determinismus zu tun.
Also: 'Ich lege erst los, wenn ich sicher bin, dass ich alle Informationen habe' und 'Ich mülle den Code nicht mit totem Code zu, den ich nur 1x beim Systemstart benötige'.
Also if systemstart() {
....
} endif
finde ich persönlich nicht schlimmer als [SystemStart]
....
Das ist m.E. Geschmacksache. Der "tote" Code wird sowieso ignoriert - geschätzte 99.5% des Codes dürfte während einer Verarbeitung eh tot sein, weil sich dort kein Objekt ändert und damit auch den EibPC nicht belastet - das ist zumindest mit dem neuen Scheduler (ab v1.094) so.
ich komme mit der Version, wo ich gezielt bei Systemstart() Adressen abfragen kann besser zurecht. Bei einer Version, die alles vorhandene abfragt (HS) haben mir die Abfragen an mehrfach benutzte Adressen über die darauf gegebenen Antworten oft irgendwelche Sachen ein- oder ausgeschaltet. Das passiert mir beim EibPC nicht mehr.
Mein Makro für webbuttons fragt die entsprechende Adressen beim Systemstart ab. Damit tauchen diese Adressen gar nicht im Programmteil auf und für die restlichen habe ich eine Abfrage mit "if Systemstart() then read" und dahinter 12 Adressen, wenn ich neue brauche setze ich sie bloß dahinter.
ich komme mit der Version, wo ich gezielt bei Systemstart() Adressen abfragen kann besser zurecht. Bei einer Version, die alles vorhandene abfragt (HS) haben mir die Abfragen über die Zentraladressen über die darauf gegebenen Antworten oft irgendwelche Sachen ein- oder ausgeschaltet. Das passiert mir beim EibPC nicht mehr.
Ich sehe, du hast das Thema nicht verstanden. Die Leseanforderungen deines eibPCs werden, auch in Makros, die entsprechenden Aktionen auslösen, so oder so.
Und ich bin nicht derjenige, der sagt, dass man ALLE GAs abfragen muss. Ich sage, dass man die Abfragen in einen [Startbereich] packen kann und dort auch noch das tatsächliche Eintreffen abwarten kann und dann erst den restlichen Code ausführt. Denn nur dann kann man sicher sein, dass wirklich jedes Mal auch wirklich alle benötigten Informationen eingetroffen sind und sich der eibPC deterministisch, d.h. immer gleich verhält, egal wann ich ihn starte. Und das ist eben ein großes Problem für jeden neuen Code. Siehe auch wieder dieses Code-Beispiel.
Mein Makro für Webbuttoms fragt die entsprechende Adressen beim Systemstart ab. Damit tauchen diese Adressen gar nicht im Programmteil auf und für die restlichen habe ich eine Abfrage mit "if Systemstart() then read" und dahinter 12 Adressen, wenn ich neue brauche setze ich sie bloß dahinter.
Ist eigendlich recht übersichtlich.
Es ist klar, dass bei dir alles besser ist. Du kannst das bestimmt klar verständlich, ohne Kommentart, mit einem Zweizeiler lösen, 200 Kommandos in 2 Zeilen.
Es ist auch klar, das Michael immer eine Lösung für jedes Problem parat hat, mag sie noch so komplex sein.
Es geht aber nicht um die vorhandene Lösung, sondern um eine neue Lösung. GAs beim Systemstart im Makro abzufragen hilft nur die entsprechenden Aufrufe nicht zu vergessen und den Code im Makro zu verstecken. Die Probleme werden damit nicht behoben. Wir hatten das Thema ja schon bei der ntp-Uhrzeit. Ein simples after(systemstart(),5000u64) hilft leider nicht, wenn die Nachricht nicht kommt. Da muss man schon etwas mehr einbauen. Und dank Validierungsschema ist der Aufwand für diese Logik dann enorm und das steht dann alles im Code. Das macht alles eben nicht lesbarer.
saft6luck, das war ja auch mal mein Gedanke dieses Beispiel hier zu posten und anzuregen sich ernsthaft Gedanken hierüber zu machen, ggf. eine Lösung in die Makros ggf. Systemstart eintragen.
kann mir schlecht vorstellen, dass dies nur mir aufgefallen bez. nur ich betroffen bin.
Und ich bin nicht derjenige, der sagt, dass man ALLE GAs abfragen muss. Ich sage, dass man die Abfragen in einen [Startbereich] packen kann und dort auch noch das tatsächliche Eintreffen abwarten kann und dann erst den restlichen Code ausführt.
Nur das hieße in letzter Konsequenz, wenn eine Adresse nicht antwortet, läuft das Programm nicht an?!
jetzt verstehe ich erst so richtig was Marc gemeint hat.
Hmm, kann ich nachvollziehen und das wäre gar nicht mal so schlecht, glaube ich.
Wie könnte man das lösen?
Einen extra []-Abschnitt dafür bräuchte ich nicht, mir würde ein extra Codebereich wie es Andreas macht (so mach ich es auch) reichen.
Wenn ich die Readanforderung schicke, dann dauert das unter Umständen etwas bis die Daten da sind und in der Zeit könnte schon etwas ausgelöst sein, was ich nicht möchte.
Wenn ich aber die Verarbeitung verzögere, bis alles da ist, dann beginnt die Verarbeitung nie.
Wäre es eine Lösung den kompletten Programmstart oder die Weiterverarbeitung verzögern zu können?
Muss ich mal drüber Nachdenken.
Just my 2cents zum jetzigen Überlegungsstand...
kann mir schlecht vorstellen, dass dies nur mir aufgefallen bez. nur ich betroffen bin.
Karl-Heinz. ICh hatte das auch 2-mal.
Lösung bei mir ist das if systemstart() {
....
} endif
ganz am Anfang des Programmcodes.
Da lese ich ein paar Sachen ein und seitdem hatte ich das nicht mehr.
Deshalb hab ich auch nicht mehr darüber nachgedacht.
Volker, habe anfänglich auch keine Gedanken hierzu verschwendet da beim HS diese Thematik ein wenig anders abläuft. Doch wie es so ist im Leben kam mir der Zufall zu Hilfe.
Nur das hieße in letzter Konsequenz, wenn eine Adresse nicht antwortet, läuft das Programm nicht an?!
Die Frage kann ich nicht beantworten und der eibPC eben auch nicht (auch wenn er es versucht ).
Wenn kein wirklicher Fehler vorliegt, sondern nur das Telegramm nicht durch kam, könnte eine 2. Anfrage helfen.
Immer vorrausgesetzt die GA liefert nichts (z.B. Defekt), gibt es eine Vielzahl an Möglichkeiten, die zur jeweiligen Anwendung passen müssen. Man überlegt sich dann also einen Fallback, der gerne auch mehrstufig sein kann.
- Temperaturabhängige Aktionen können einen 'neutralen' Default Wert erhalten oder einen alternativen Messwert
- Uhrzeit könnte aus dem Zeitmodul gelesen werden
- Lampe war ein, aber DALI meldet Fehler und somit ist der Zustand AUS
- etc. etc.
... und dann gleich noch eine Mail an den Hausherren absetzen.
Da sind die Möglichkeiten grenzenlos und die Anforderung immer öfter vorhanden (jedenfalls geht es mir so).
Wäre es eine Lösung den kompletten Programmstart oder die Weiterverarbeitung verzögern zu können?
Da würde ich ansetzen und nur deshalb der eigene Bereich. Dann gibt es eine klare Abgrenzung: Initialisierung <-> Programm
Die Idee des [systemstart] Bereiches ist dann ja auch, die Ausführung (wenn verwendet!) so lange verzögern zu können, bis man die eigentliche Programmausführung explizit erlaubt.
Eine definierte (einstellbare) Verzögerung zwischen den "Systemstart- read" Anfragen und dem Start des Rest Programmes fände ich auch nicht schlecht.
Teilweise kann man sich aber auch mit der "event"-Funktion weiterhelfen, da diese erst vom Rückgabewert nach der Anfrage getriggert wird.
Das Problem könnte auch mit dem remanenten Speicherbereich gelöst werden. Dann könnte man kritsche Abfragen remanent Zwischenspeichern bzw. vorbelegen und danach normal nach dem Standard-Systemstart oder von dem zyklischen Senden aktualisieren lassen.
Eine definierte (einstellbare) Verzögerung zwischen den "Systemstart- read" Anfragen und dem Start des Rest Programmes fände ich auch nicht schlecht.
Eine andere Idee wäre die sleep()-Funktion zu nutzen und erst so nach 10 Sekunden, den EibPC wieder online schalten (das hab ich aber noch nicht getestet): if systemstart() then {
read()....
sleep(EIN)
}
if after(systemstart(),10000u64) then sleep(AUS) endif
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
).
Kommentar