Neue Hauptversion V 4.1.1 mit Bugfix verfügbar
Dies ist die Fehlerkorrekturversion zur V 4.1 mit Fix für Kompatibilität der Tunnel, u.a. für ETS 6.3.0
Wir haben den seit 2019 bereitgestellten KNXnet/IP Tunneling Server im Timberwolf Server erweitert für Kompatibilität mit aktuellen Anforderungen der ETS 6.3 und weiterer Software, z.B. Weinzierl ENO Tools
Alle Informationen hier: https://elabnet.atlassian.net/wiki/page ... 3100770306
Dies ist die Fehlerkorrekturversion zur V 4.1 mit Fix für Kompatibilität der Tunnel, u.a. für ETS 6.3.0
Wir haben den seit 2019 bereitgestellten KNXnet/IP Tunneling Server im Timberwolf Server erweitert für Kompatibilität mit aktuellen Anforderungen der ETS 6.3 und weiterer Software, z.B. Weinzierl ENO Tools
Alle Informationen hier: https://elabnet.atlassian.net/wiki/page ... 3100770306
[TIPP] Zähler Universalbaustein
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
- Reactions:
- Beiträge: 1907
- Registriert: Di Okt 09, 2018 9:26 am
- Hat sich bedankt: 642 Mal
- Danksagung erhalten: 796 Mal
Bevor wir weiter in Code abdriften und den vergleichen. Lass uns einmal defininiere (und dazu ist jeder eingeladen mitzumachen), was wir in den Baustein drin haben wollen.
Mein Ansatz war
- Wert wird immer am Ender eine Persiode gesendet
- Es vier relevante Perioden (TAG, WOCHE, MONAT, JAHR)
- Je vollständig abgelaufener Periode wünsche ich mir den Zählerendstand und den Verbauch
- von der aktuellen Periode, die noch nicht abgelaufen ist, möchte ich jederzeit den aktuellen Verbrauch haben.
Alles andere würde ich entweder in Grafana oder in nachgeschalteten Logiken lösen wollen.
Robert hält in seiner Logik beispielsweise die letzten drei Zählerstände bereit. Verutlich matched er diese auf KNX-Adressen um sie in der CV darzustellen(korrekt Robert).
Das wäre aus meiner Sicht nicht Aufgabe dieser Logik und gehört für mich in eine eigene Logik.
Denn es bläht die Logik unnötig auf. Der nächst möchte anstelle der letzten drei Zählerstände 5...der nächste lieber gleich 12 und der wieder nächste möchte nicht die Zählerstände, sondern Verbräuche...Das alles ist über einen einfachen Multiplexer schnell und individuell gelöst. Dafür könnten wir ja auch Ergänzungsvorschlag erarbeiten.
Mein Ansatz war
- Wert wird immer am Ender eine Persiode gesendet
- Es vier relevante Perioden (TAG, WOCHE, MONAT, JAHR)
- Je vollständig abgelaufener Periode wünsche ich mir den Zählerendstand und den Verbauch
- von der aktuellen Periode, die noch nicht abgelaufen ist, möchte ich jederzeit den aktuellen Verbrauch haben.
Alles andere würde ich entweder in Grafana oder in nachgeschalteten Logiken lösen wollen.
Robert hält in seiner Logik beispielsweise die letzten drei Zählerstände bereit. Verutlich matched er diese auf KNX-Adressen um sie in der CV darzustellen(korrekt Robert).
Das wäre aus meiner Sicht nicht Aufgabe dieser Logik und gehört für mich in eine eigene Logik.
Denn es bläht die Logik unnötig auf. Der nächst möchte anstelle der letzten drei Zählerstände 5...der nächste lieber gleich 12 und der wieder nächste möchte nicht die Zählerstände, sondern Verbräuche...Das alles ist über einen einfachen Multiplexer schnell und individuell gelöst. Dafür könnten wir ja auch Ergänzungsvorschlag erarbeiten.
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
-
- Reactions:
- Beiträge: 1907
- Registriert: Di Okt 09, 2018 9:26 am
- Hat sich bedankt: 642 Mal
- Danksagung erhalten: 796 Mal
Noch was zum mehrfachen, gleichzeitigen Triggern am Ende einer längeren Periode. Das Ganze taucht in folgenden Konstellationen auf:
Ich glaube es nimmt sich Beides nichts. Eventuel sollten wir das Triggern einfach um eine Sekunde versetzen:
tägliches um 23:59:56
wöchtenliche um 23:59:57
monatlich um 23:59:58
jährlich um 23:59:59.
Was meint Ihr?
- Jahresende (3xtrigger)
- Monatsende (2xtrigger)
- Wochen-Ende (2Xtrigger)
- Special: Monatsende fällt zusammen mit Ende der Wochen(3x trigger)
- Superspecial: Monatsende fällt zusammen mit Ende der Woche auf das Ende des Jahres (4x trigger)
Ich glaube es nimmt sich Beides nichts. Eventuel sollten wir das Triggern einfach um eine Sekunde versetzen:
tägliches um 23:59:56
wöchtenliche um 23:59:57
monatlich um 23:59:58
jährlich um 23:59:59.
Was meint Ihr?
Zuletzt geändert von Robosoc am So Okt 09, 2022 5:08 pm, insgesamt 1-mal geändert.
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
-
- Reactions:
- Beiträge: 3895
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1259 Mal
- Danksagung erhalten: 2205 Mal
Hallo Sven!
Zum Scope: soweit einverstanden, Vortag ist bei mir nichts anderes, als die Zählerwerte bei dir für die Zeitserien.
Der Unterschied ist nur 1sec => bei dir „end of day“ / bei mir 2s später der „Vortag“…
Was ich noch möchte:
Die Möglichkeit, werte zyklisch zu senden. Zumindest Wochen/Monats/Jahreswerte möchte ich 1x/Tag am Bus, sonst sieht man sie nach einem Reboot den Rest des Monats/Jahres nicht. Ich hab da auch in der Zeitserie kein Problem damit…
Lg
Robert
Zum Scope: soweit einverstanden, Vortag ist bei mir nichts anderes, als die Zählerwerte bei dir für die Zeitserien.
Der Unterschied ist nur 1sec => bei dir „end of day“ / bei mir 2s später der „Vortag“…
Was ich noch möchte:
Die Möglichkeit, werte zyklisch zu senden. Zumindest Wochen/Monats/Jahreswerte möchte ich 1x/Tag am Bus, sonst sieht man sie nach einem Reboot den Rest des Monats/Jahres nicht. Ich hab da auch in der Zeitserie kein Problem damit…
Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 3895
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1259 Mal
- Danksagung erhalten: 2205 Mal
Zur Mehrfachausführung:
Ich würde die 2 ersten Fälle abfangen, der Rest wär mir zu kompliziert.
Zusätzlich ein paar sec verteilen-fertig.
Robert
Ich würde die 2 ersten Fälle abfangen, der Rest wär mir zu kompliziert.
Zusätzlich ein paar sec verteilen-fertig.
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 3895
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1259 Mal
- Danksagung erhalten: 2205 Mal
Sehe zwar keinen Fehler, hab den Code trotzdem oben nochmal neu eingefügt.
Lg
Robert
Zuletzt geändert von Robert_Mini am So Okt 09, 2022 1:34 pm, insgesamt 1-mal geändert.
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 1907
- Registriert: Di Okt 09, 2018 9:26 am
- Hat sich bedankt: 642 Mal
- Danksagung erhalten: 796 Mal
Die letzten 4 Ausgänge in meiner Logik hatte ich in einer zwischenzeitliche Bastelversion auf ct stehen und dann habe ich einfach einen trigger Eingang aktiviert um zyklisch aktuelle Werte auszugeben.
Würde das nicht reichen?
Würde das nicht reichen?
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
-
- Reactions:
- Beiträge: 3895
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1259 Mal
- Danksagung erhalten: 2205 Mal
Aus meiner Sicht ja, wenn zusätzlich intern ein Latch sicherstellt, dass nur nach Ablauf von min_interval der Wert auf den Aufgang geschrieben wird. Sonst spricht das „c“ zu oft an.
Wir reden von den Eingängen 1-8, oder?
Wir reden von den Eingängen 1-8, oder?
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 1907
- Registriert: Di Okt 09, 2018 9:26 am
- Hat sich bedankt: 642 Mal
- Danksagung erhalten: 796 Mal
Hallo Robert
Den Block meinte ich. Also von dem würde ich sagen, dass er nicht unbedingt in die Universallogik sollte.
Code: Alles auswählen
["Multiplexer",["$ZaehlerWoche2","$ZaehlerWoche3"],"$ZaehlerWoche3","$New1"],
["Multiplexer",["$ZaehlerMonat2","$ZaehlerMonat3"],"$ZaehlerMonat3","$New1"],
["Multiplexer",["$ZaehlerJahr2","$ZaehlerJahr3"],"$ZaehlerJahr3","$New1"],
["Multiplexer",["$ZaehlerGes2","$ZaehlerGes3"],"$ZaehlerGes3","$New1"]
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
-
- Reactions:
- Beiträge: 1907
- Registriert: Di Okt 09, 2018 9:26 am
- Hat sich bedankt: 642 Mal
- Danksagung erhalten: 796 Mal
Du meintest hier sicher Ausgängen statt Eingängen, oder?
Aber ich meinte in meiner Logik in Beitrag #1 die Ausgänge 9-12.
Das sind Werte, die sich innerhalb der Periode stetig ändern. Die könnte man mit dem Verhalten 't' (defintiv besser als ct) und einem Triggereingang zyklisch schreiben, allerdings werden sie dann bei jedem internen Cron- Timer- Ablauf auch geschrieben ( also im Moment zu Sylverster 3x).

Die Ausgänge 1-8 würde ich persönlich bewusst nicht zyklisch schreiben wollen. Da würde ich jetzt keinen Sinn drinnen sehen.
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
-
- Reactions:
- Beiträge: 3895
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1259 Mal
- Danksagung erhalten: 2205 Mal
Nein ich meine schon die Ausgänge 1-8.
Hintergrund: nach einem Neustart liegen die Werte zwar wieder in der Logik vor, werden aber bis zum nächsten Ereignis (im schlimmsten Fall knapp 1 Jahr bis zum nächsten Jahreswechsel) nicht mehr an den Dispatcher durchgereicht und können daher auch nicht vom KNX per READ gelesen werden!
Daher braucht es dieses aktive Senden, wenn man die Werte am Bus (auf der Visu) anzeigen will...
In den Zeitserien ist das aber störend, deshalb habe ich auch schon an 2 Ausgänge je Wert gedacht
Den Code, den du oben zitierst braucht man, um das Senden "on change" auf ein Mindestintervall zu verlängern, ansonsten wird jeder eintreffende Zählerstand gleich auch wieder x-mal gesendet, was ich am KNX nicht brauchen kann.
=> Zählerstände werden erst am Ausgang aktualisiert, wenn der Timer mit dem Mindestintervall abgelaufen ist.
lg
Robert
Hintergrund: nach einem Neustart liegen die Werte zwar wieder in der Logik vor, werden aber bis zum nächsten Ereignis (im schlimmsten Fall knapp 1 Jahr bis zum nächsten Jahreswechsel) nicht mehr an den Dispatcher durchgereicht und können daher auch nicht vom KNX per READ gelesen werden!
Daher braucht es dieses aktive Senden, wenn man die Werte am Bus (auf der Visu) anzeigen will...
In den Zeitserien ist das aber störend, deshalb habe ich auch schon an 2 Ausgänge je Wert gedacht



Den Code, den du oben zitierst braucht man, um das Senden "on change" auf ein Mindestintervall zu verlängern, ansonsten wird jeder eintreffende Zählerstand gleich auch wieder x-mal gesendet, was ich am KNX nicht brauchen kann.
=> Zählerstände werden erst am Ausgang aktualisiert, wenn der Timer mit dem Mindestintervall abgelaufen ist.
lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297