Beispiel für dem Umgang mit Schaltzeiten
Verfasst: Mo Dez 28, 2020 3:33 pm
Hallo zusammen,
Robert hat mich in diesem Post hier: viewtopic.php?f=65&t=2555#p28682 dazu motiviert, mal was zu meinem Lösungsansatz mit Schaltzeiten in der CometVisu zu schreiben.
Meine Lösung ist leider wieder nicht so einfach kompatibel zu den hier im Formum bereits geposteten Logiken zur Zeitfenstersteuerung bzw. neuen ZSU-Logik.
Ich hatte meine Schaltzeiten bereits als DPT 10.001 vorliegen und habe daher die erwähnten Logiken entsprechend anpassen müssen. Ich sende also nicht Stunde, Minute und Sekunde als getrennte Werte in die hier bekannten Logikbausteine.
Die Entscheidung mit dem DPT 10.001 zu arbeiten ist bei mir schon ewig alt, da ich hoffe damit zu den dann mal kommenden Standardlösungen von Elabnet kompatibel zu sein und sich dann die Umbauaufwände in Grenzen halten, wenn ich meine Interimslösungen gegen den Standard tauschen will.
Für mich ergab sich dann, dass wenn ich hier mit Schaltzeiten arbeiten will, für mich um den DPT 10.001 eigentlich kein Weg vorbei geht. Weil das der KNX-Standard einfach mal so vorsieht. Nun hat die CometVisu im Umgang mit diesem DPT nun leider nicht gerade ihre Stärken, zumindest was das Schreiben eines solchen Wertes angeht. (siehe dazu auch hier: viewtopic.php?f=37&t=1018)
Also sieht meine Lösung jetzt so aus, dass ich pro Schaltzeit zwei Objekte und zwei GA's im Einsatz habe. Jeweils einmal vom DPT 12.001 und einmal dann DPT 10.001.
Mit dem DPT 12.001 bastele ich mir dann originär über die CV die jeweiligen Sekunden ab Mitternacht zusammen, also im Wertebereich zwischen 0 und 86399. Das Ganze pro Uhrzeit in der CV mit jeweils zwei Infotriggern, einmal für Stunde und dann Minute. Zur Darstellung der Ergebnisuhrzeit nutze ich dann in der CV bereits die GA mit dem DPT 10.001.
Um die Übernahme des DPT 12.001-Wertes in das zugehörige DPT 10.001-Objekt des Wolfes, bzw. der damit verbundene GA zu bewerkstelligen, habe ich im "Objekt Manager" die beiden Objekte verknüpft.
Das sieht dann dazu konkret so aus:
Der auf ein rudimentäres Minimum reduzierte Code aus der CV:
Der Aufbau der Weiterleitung im "Objekt Manager" sieht dann so aus:
Beste Grüße
Jens
Robert hat mich in diesem Post hier: viewtopic.php?f=65&t=2555#p28682 dazu motiviert, mal was zu meinem Lösungsansatz mit Schaltzeiten in der CometVisu zu schreiben.
Meine Lösung ist leider wieder nicht so einfach kompatibel zu den hier im Formum bereits geposteten Logiken zur Zeitfenstersteuerung bzw. neuen ZSU-Logik.
Ich hatte meine Schaltzeiten bereits als DPT 10.001 vorliegen und habe daher die erwähnten Logiken entsprechend anpassen müssen. Ich sende also nicht Stunde, Minute und Sekunde als getrennte Werte in die hier bekannten Logikbausteine.
Die Entscheidung mit dem DPT 10.001 zu arbeiten ist bei mir schon ewig alt, da ich hoffe damit zu den dann mal kommenden Standardlösungen von Elabnet kompatibel zu sein und sich dann die Umbauaufwände in Grenzen halten, wenn ich meine Interimslösungen gegen den Standard tauschen will.
Für mich ergab sich dann, dass wenn ich hier mit Schaltzeiten arbeiten will, für mich um den DPT 10.001 eigentlich kein Weg vorbei geht. Weil das der KNX-Standard einfach mal so vorsieht. Nun hat die CometVisu im Umgang mit diesem DPT nun leider nicht gerade ihre Stärken, zumindest was das Schreiben eines solchen Wertes angeht. (siehe dazu auch hier: viewtopic.php?f=37&t=1018)
Also sieht meine Lösung jetzt so aus, dass ich pro Schaltzeit zwei Objekte und zwei GA's im Einsatz habe. Jeweils einmal vom DPT 12.001 und einmal dann DPT 10.001.
Mit dem DPT 12.001 bastele ich mir dann originär über die CV die jeweiligen Sekunden ab Mitternacht zusammen, also im Wertebereich zwischen 0 und 86399. Das Ganze pro Uhrzeit in der CV mit jeweils zwei Infotriggern, einmal für Stunde und dann Minute. Zur Darstellung der Ergebnisuhrzeit nutze ich dann in der CV bereits die GA mit dem DPT 10.001.
Um die Übernahme des DPT 12.001-Wertes in das zugehörige DPT 10.001-Objekt des Wolfes, bzw. der damit verbundene GA zu bewerkstelligen, habe ich im "Objekt Manager" die beiden Objekte verknüpft.
Das sieht dann dazu konkret so aus:
Der auf ein rudimentäres Minimum reduzierte Code aus der CV:
Code: Alles auswählen
<?xml version="1.0" encoding="UTF-8"?>
<pages lib_version="8" design="metal" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../visu_config.xsd">
<meta>
<plugins>
<plugin name="clock"/>
</plugins>
<mappings>
<mapping name="TimeHM">
<formula>y = x && x.constructor === Date ? x.getHours() + ':' + (x.getMinutes()<10?'0':'') + x.getMinutes() + ' Uhr' : x;</formula>
</mapping>
<mapping name="Leer">
<entry value="*"/>
</mapping>
</mappings>
<stylings>
</stylings>
<statusbar>
<status type="html"><img src="icon/comet_64_ff8000.png" alt="CometVisu" /> by <a href="http://www.cometvisu.org/">CometVisu.org</a>
- <a href=".?forceReload=true">Reload</a></status>
<status type="html" hrefextend="config" condition="!edit">- <a href="editor/">Edit</a></status>
<status type="html" hrefextend="config" condition="edit">- <a href=".">normal Mode</a></status>
<status type="html">- <a href="?config=demo">Widget Demo</a></status>
<status type="html" hrefextend="config">- <a href="check_config.php">Check Config</a></status>
</statusbar>
</meta>
<page name="Zeiten">
<layout colspan="12"/>
<group name="Frühestens auf" nowidget="false">
<layout colspan="3"/>
<infotrigger mapping="Leer" align="center" styling="- not set - (undefined)" shorttime="300" infoposition="middle" max="86399" min="0" shortdownvalue="-3600" downvalue="-14400" shortupvalue="3600" change="absolute" upvalue="14400" downlabel="-" uplabel="+">
<layout colspan="3"/>
<label>Stunde</label>
<address mode="readwrite" transform="DPT:12.001" variant="relative">12/1/0</address>
</infotrigger>
<infotrigger mapping="Leer" align="center" styling="- not set - (undefined)" shorttime="300" infoposition="middle" max="86399" min="0" shortdownvalue="-60" downvalue="-600" shortupvalue="60" change="absolute" upvalue="600" downlabel="-" uplabel="+">
<layout colspan="3"/>
<label>Minute</label>
<address mode="readwrite" transform="DPT:12.001" variant="relative">12/1/0</address>
</infotrigger>
<info align="center" mapping="TimeHM">
<layout colspan="3"/>
<label>
<icon name="time_clock"/>
</label>
<address mode="read" transform="DPT:10.001">12/1/1</address>
</info>
</group>
</page>
</pages>
- Das ist das Objekt mit dem DPT 12.001 (in der ETS mit der GA 12/1/0 verbunden)
- Und hier das vom DPT 10.001 (in der ETS mit der GA 12/1/1 verbunden)
- Das hier ist der Ausgang meiner persistierenden Logik für die Schaltzeiten (siehe dazu hier: viewtopic.php?f=65&t=1894)
- Und das eben der Eingang.
- insgesamt weniger Hilfsobjekte im Einsatz
- persistiert werden muss hier nur 1 Objekt pro Schaltzeit (der DPT 12.001-Wert)
- Hoffentlich einfacher steckerkompatibel für künftige Dinge, da Nutzung des Standarddatentyps
- Die im Doktormodus der Logiken angezeigten Werte sind nicht gerade einfach "menschenlesbar", oder habt ihr schon nachgerechnet, wofür die 32400 im Screenshot steht
. Wer also seine Schaltpunkte eh nicht über die CV editiert, ist mit der Aufspaltung der Zeiten auf Stunden/Minuten/Sekunden wohl besser dran. Aber das kann ich meiner Regierung wieder nicht zumuten. Parameter im Logikeditor ändern? Das hat wiederum leider einen gegen 0 tendierenden WAF (WomansAcceptanceFactor) 
Beste Grüße
Jens
. Hier bliebe dann "nur" noch der "Nachteil" mit den nicht dekodierten Schaltwerten im Doktormodus.