RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Benutzeravatar
jmaus
Beiträge: 10265
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 519 Mal
Danksagung erhalten: 2181 Mal
Kontaktdaten:

RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von jmaus » 12.06.2023, 10:15

Hallo Zusammen,

da ich gerade selbst drübergestolpert bin, möchte ich hier gerne eine aktuelle Idee für das Einführen zwei neuer Datenpunkt-Funktionen in der ReGa zur Diskussion stellen.

Das aktuelle Problem ist, das es z.B. Geräte wie den HmIP-SMI55, etc. gibt der in einem einzelnen Kanal mehrere Datenpunkte vereint die regelmäßig vom Gerät aktualisiert werden, die aber eine andere Funktion bzw. im Grund inhaltlich nichts miteinander zu tun haben. So hat ein HmIP-SMI55 in Kanal 3 ja z.B. den Datenpunkt "MOTION" um die Bewegung (true/false) wiederzugeben, aber eben auch "CURRENT_ILLUMINATION" oder "ILLUMINATION" um den aktuellen Helligkeitswert wiederzugeben. Das Problem dabei ist jedoch (soweit ich das überblicke), das es aktuell nicht möglich ist herauszubekommen zu welcher Zeit eine konkrete Änderung (d.h. wann der Wert anders war als der letzte) des Datenpunktwertes stattgefunden hat.

Konkret zu sehen ist das z.B. an folgendem Beispielskript den man mal auf solche Bewegungsmelder mit Helligkeitsinformationen loslassen kann:

Code: Alles auswählen

string kanalname = "Licht-Bewegungsmelder:3";
string dpname = "MOTION";
WriteLine("DP: "#kanalname#":"#dpname);
WriteLine("DP Value: "#dom.GetObject(kanalname).DPByHssDP(dpname).Value());
WriteLine("DP LastValue: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastValue());
WriteLine("DP Timestamp: "#dom.GetObject(kanalname).DPByHssDP(dpname).Timestamp());
WriteLine("DP LastTimestamp: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastTimestamp()); 
WriteLine("DP LastTriggerTime: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastTriggerTime());
! WriteLine("DP LastDPActionTime: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastDPActionTime()) ; ! geht gar nicht
WriteLine("Kanal LastDPActionTime: "#dom.GetObject(kanalname).LastDPActionTime()) ; 
WriteLine("Kanal LastTimestamp: "#dom.GetObject(kanalname).LastTimestamp()) ; 
WriteLine("DONE“);
Führt man diesen Skript nun aus, so erhält man mitunter die folgende Ausgabe:

Code: Alles auswählen

DP: Licht-Bewegungsmelder:3:MOTION
DP Value: false
DP LastValue: false
DP Timestamp: 2023-06-12 09:25:09
DP LastTimestamp: 2023-06-12 09:22:41
DP LastTriggerTime: 1970-01-01 01:00:00
Kanal LastDPActionTime: 2023-06-12 09:25:09
Kanal LastTimestamp: 2023-06-12 09:25:09
DONE
D.h. wie man sehen kann ist Value() und LastValue() beides mal "false", die Timestamp() und LastTimestamp() Werte sind jedoch um ca 3 Minuten unterschiedlich. Im Grunde bedeutet das also das der Bewegungsmelder einmal um 09:22 ein "false" geliefert hat und dann danach eben auch um 09:25 erneut "false" gemeldet hat. Das Problem hierbei ist jedoch, das das nur passiert weil im selben Kanal 3 es eben auch ein "CURRENT_ILLUMINATION" Datenpunkt gibt der auch regelmäßig aktualisiert wird und dann eben in diesem Ablauf auch der neue MOTION Wert mit übertragen wird und das eben zu dem Zeitpunkt der Wert wieder "false" war. Die ReGaHss macht jedoch hier anscheinend keine Änderungsprüfung und setzt hier stumpf den aktuellen Wert in das LastValue und merkt sich den Zeitpunkt dieser Aktion dann in Timestamp().

Wenn man aber nun eben daran interessiert ist für diesen MOTION Datenpunkt herauszubekommen wann konkret der letzte Zeitpunkt war als der Datenpunkt "true" bzw. eben anders als aktuell war, dann hat man soweit ich das sehen kann keinerlei Möglichkeit das herauszubekommen.

Nun könnte man natürlich argumentieren das man doch einfach genau diese Value() vs. LastValue() doch so ändern sollte das hier immer eine Änderungsprüfung passieren sollte. D.h. Value() und LastValue() immer unterschiedlich sein müssten und er einfach eine weitere Value-Änderung auf den selben wert (false -> false) komplett ignorieren sollte. So ganz sicher bin ich mir hier jedoch nicht ob das so eine kluge Idee wäre bzw. was das dann konkret für Auswirkungen hätte wenn man das nun so anpassen würde.

Deshalb wäre hier vielleicht die Alternative eine weitere Funktion "LastChangeValue()" und "LastChangeTimestamp" einzuführen die einerseits den konkreten Wert der letzten Änderung != des aktuellen Wertes beinhaltet und eben auch den Zeitpunkt dieser letzten Änderung.

Bevor ich mich nun aber eben ans Werk mache möchte ich diese Idee natürlich gerne gerade bei unseren "ReGa-Experten" zur Diskussion stellen damit sichergestellt ist, das ich nicht irgendetwas gedanklich übersehe bzw. es vllt. doch einen anderen einfacheren Weg gibt oder man doch einfach nur die Logik wie Value() und LastValue() gesetzt werden ändern/repaieren sollte..

Daher wäre es natürlich schön wenn soviele ReGa-Interessierte Entwickler wie möglich hier beim Brainstorming mitmachen könnten bevor ich mich nun ans Werk mache :mrgreen:
RaspberryMatic 3.81.5.20250326 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
Black
Beiträge: 5798
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 482 Mal
Danksagung erhalten: 1215 Mal
Kontaktdaten:

Re: RFC: Neue LastValueChange/LastValueChangeTime Funktionen für DP in ReGa?

Beitrag von Black » 12.06.2023, 12:28

Klingt eigentlich stimmig.
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Benutzeravatar
Baxxy
Beiträge: 13219
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Berlin
Hat sich bedankt: 806 Mal
Danksagung erhalten: 2897 Mal

Re: RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von Baxxy » 12.06.2023, 18:32

Braucht man das in Zeiten von CCU-Historian, Grafana, ioBroker, Homeassistant usw. wirklich?

Ich habe zumindest keine Probleme zu sehen wann sich was (ich :mrgreen: ) bewegt hat.
SMI55_HA_Overview.JPG
Die zusätzlichen Informationen könnte/müsste man ja dann auch wieder mittels Scripting nutzen und Scripte sind doch bekanntlich böse.
Zumindest habe ich im Kopf das davon abgeraten wird. :wink:

Definitiv dagegen bin ich, das aktuelle Verhalten von LastValue() zu ändern. Ich breche viele Scripte direkt ab wenn Value() == LastValue().
Das müsste dann alles umgebaut werden weil dann LastValue() immer != Value() wäre. Machbar, klar... aber unnötiger Aufwand.

Erweitern um zusätzliche Optionen finde ich aber grundsätzlich ok.
Wenn es die 2 Zusatzinformationen (warum nicht auch LastChangeTimestampSeconds() ?) dann aber für jeden Datenpunkt gibt sind das m.E. jede Menge unnütze Daten die vermutlich nie einer braucht.
(Mein SMI55 hat 26 Datenpunkte, 2 zusätzliche Informationen pro DP machen dann schon mal 52 und bei 3 zusätzlichen Informationen sind es 78 zusätzliche Informationen.)
Da läppert sich was zusammen wenn man einen ordentlichen Gerätefuhrpark hat. Packt die ReGa das?

Benutzeravatar
jmaus
Beiträge: 10265
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 519 Mal
Danksagung erhalten: 2181 Mal
Kontaktdaten:

Re: RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von jmaus » 12.06.2023, 18:53

Baxxy hat geschrieben:
12.06.2023, 18:32
Braucht man das in Zeiten von CCU-Historian, Grafana, ioBroker, Homeassistant usw. wirklich?

Ich habe zumindest keine Probleme zu sehen wann sich was (ich :mrgreen: ) bewegt hat.
Ja, braucht man IMHO z.B. für sowas wie PocketControl das via ReGa-Skripting viele Dinge abfragt und nicht selbst wie ioBroker, etc. in der Lage ist ein eigenes ChangeTracking zu machen – einfach weil es ja nicht 24/7 läuft wie die Middleware-Produkte die du da gelistet hast. Und eben wenn man innerhalb der ReGa oder WebUI eben die letzte Änderung eines DP wirklich reproduzierbar genauso wie das ioBroker, HomeAssistant, etc. macht abbilden will (können wir ja dann in zukünftigen WebUI Patches mit verwenden...)
Baxxy hat geschrieben:
12.06.2023, 18:32
[...]
Erweitern um zusätzliche Optionen finde ich aber grundsätzlich ok.
Wenn es die 2 Zusatzinformationen (warum nicht auch LastChangeTimestampSeconds() ?) dann aber für jeden Datenpunkt gibt sind das m.E. jede Menge unnütze Daten die vermutlich nie einer braucht.
(Mein SMI55 hat 26 Datenpunkte, 2 zusätzliche Informationen pro DP machen dann schon mal 52 und bei 3 zusätzlichen Informationen sind es 78 zusätzliche Informationen.)
Da läppert sich was zusammen wenn man einen ordentlichen Gerätefuhrpark hat. Packt die ReGa das?
Das sind Peanuts ehrlich gesagt. Wir reden hier von einer zusätzlichen IseValue und einem time_t wert die je DP im Speicher gehalten werden müssen. Da geht es um wenige Bytes pro DP und Performance-technisch auch IMHO total unkritisch.
RaspberryMatic 3.81.5.20250326 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
Baxxy
Beiträge: 13219
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Berlin
Hat sich bedankt: 806 Mal
Danksagung erhalten: 2897 Mal

Re: RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von Baxxy » 12.06.2023, 19:45

Gut gut... ich denke mir schon die ersten Einsatzszenarien aus. 8)

Ich wünsche mir dann aber Vollständigkeit und Konsistenz zu bisherigen Informationen, also inklusive
"LastChangeTimestampSeconds()"

Benutzeravatar
jmaus
Beiträge: 10265
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 519 Mal
Danksagung erhalten: 2181 Mal
Kontaktdaten:

Re: RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von jmaus » 12.06.2023, 20:44

Baxxy hat geschrieben:
12.06.2023, 19:45
Gut gut... ich denke mir schon die ersten Einsatzszenarien aus. 8)
Könnte man das vllt. sogar sinnvoll für den noch offenen Punkt bzgl. Anzeige das nach einem Reboot gewisse Geräte (vor allem HmIP) noch keine Updates gesendet haben einsetzen damit man da je Kanal/Gerät eine Warnung anzeigen kann?!?!
Baxxy hat geschrieben:
12.06.2023, 19:45
Ich wünsche mir dann aber Vollständigkeit und Konsistenz zu bisherigen Informationen, also inklusive
"LastChangeTimestampSeconds()"
Das ist bereits so umgesetzt. Hab ich nur hier unterschlagen zu erwähnen :mrgreen:

Aber gut, dann gibt es ja bis jetzt keine anderen Meinungen bzw. gegenteilige Argumente gegen das einführen dieser neuen Funktionen. Dann werd ich mal schauen ob ich das zeitnah integriert bekomme damit es bereits mit der nächsten RaspberryMatic Version kommen kann. Das man dann jedoch für eine gewisse Zeit eine Unterscheidung zwischen CCU3 (alte ReGa) und RaspberryMatic (neue ReGa) braucht versteht sich natürlich von selbst :mrgreen:
RaspberryMatic 3.81.5.20250326 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
jmaus
Beiträge: 10265
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 519 Mal
Danksagung erhalten: 2181 Mal
Kontaktdaten:

Re: RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von jmaus » 13.06.2023, 13:46

Ok, mit dem nächsten nightly snapshot von RaspberryMatic (morgen) sollte nun ReGaHss R1.00.0388.0235 mitkommen die die folgenden neuen Funktionen

Code: Alles auswählen

LastChangeValue()
LastChangeTimestamp()
LastChangeTimestampSeconds()
mit sich bringen sollte die man entsprechend auf Datenpunkte (nicht auf Kanäle!) anwenden kann und die dann eben zur Ausgabe des Wertes und des Zeitpunktes der letzten Änderung des Datenpunktes bezogen auf den aktuellen Wert genutzt werden kann.

Konkret kann man dann z.B. mit folgendem ReGa-Skript alle möglichen Value und Timestamp Funktionen für einen Datenpunkt inkl. dessen zugehörigen Kanals nutzen:

Code: Alles auswählen

string kanalname = "Licht-Bewegungsmelder:3";
string dpname = "MOTION";
WriteLine("DP: "#kanalname#":"#dpname);
WriteLine("DP Value: "#dom.GetObject(kanalname).DPByHssDP(dpname).Value());
WriteLine("DP LastValue: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastValue());
WriteLine("DP LastChangeValue: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastChangeValue());
WriteLine("DP Timestamp: "#dom.GetObject(kanalname).DPByHssDP(dpname).Timestamp());
WriteLine("DP LastTimestamp: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastTimestamp()); 
WriteLine("DP LastChangeTimestamp: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastChangeTimestamp()); 
WriteLine("DP LastTriggerTime: "#dom.GetObject(kanalname).DPByHssDP(dpname).LastTriggerTime());
WriteLine("Kanal LastDPActionTime: "#dom.GetObject(kanalname).LastDPActionTime()) ; 
WriteLine("Kanal LastTimestamp: "#dom.GetObject(kanalname).LastTimestamp()) ; 
WriteLine("DONE");
Um entsprechendes breites testen dieser neuen Funktionen wird natürlich gebeten. Und das man für den Einsatz dieser neuen Funktionen aktuell noch eine Prüfung der ReGaHss Version braucht versteht sich hoffentlich von selbst, denn kleiner Version R1.00.0388.0235 werden Skripte ansonsten in einen ScriptRuntimeError laufen weil es da diese LastChangeValue()/LastChangeTimestamp()/LastChangeTimestampSeconds() Funktionen ja noch nicht gibt.
RaspberryMatic 3.81.5.20250326 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

[sprotte80]
Beiträge: 394
Registriert: 05.10.2020, 18:37
System: CCU
Hat sich bedankt: 37 Mal
Danksagung erhalten: 35 Mal

Re: RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von [sprotte80] » 13.06.2023, 17:54

Hi
jmaus hat geschrieben:
13.06.2023, 13:46
denn kleiner Version R1.00.0388.0235 werden Skripte ansonsten in einen ScriptRuntimeError laufen
nö bestimmt nich
jmaus hat geschrieben:
13.06.2023, 13:46
Und das man für den Einsatz dieser neuen Funktionen aktuell noch eine Prüfung der ReGaHss Version braucht versteht sich hoffentlich von selbst,
kann man halt nich in dem Script tun wo ausgeführt wird.

Thomas
Wenn du keine App zur Bedienung brauchst, dann hast du kein Smarthome, sondern nur eine angefangene Baustelle, oder nur ein unsmartes Autohome.

Homematic-Script - ScriptLexikon für alle
Methoden Konstanten
Hilfe und Infos erwünscht. Alle können mitmachen. Keine Levels. Keine Geheimtuerei.

Benutzeravatar
Black
Beiträge: 5798
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 482 Mal
Danksagung erhalten: 1215 Mal
Kontaktdaten:

Re: RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von Black » 13.06.2023, 18:10

jmaus hat geschrieben:
13.06.2023, 13:46
(...)

Code: Alles auswählen

LastChangeValue()
LastChangeTimestamp()
LastChangeTimestampSeconds()
(...)
ok, dann baue ich das bei mir auch ein, wenn das so zeitnah kommt.

nur kurz zum allgemeinen Abgleich

LastChangeValue():
ReadOnly
Ergebnistyp: variant
anwendbar auf Object Classes: OT_ALARMDP,OT_CALENDARDP,OT_COMMDP,OT_DP,OT_HISTORYDP,OT_HSSDP,OT_IPDP,OT_IRDP,OT_KNXDP,OT_MAPDP,OT_OCEANDP,OT_RFDP,OT_TIMERDP,OT_UPNPDP,OT_VARDP

LastChangeTimestamp():
ReadOnly
Ergebnistyp: time
anwendbar auf Object Classes: OT_ALARMDP,OT_CALENDARDP,OT_COMMDP,OT_DP,OT_HISTORYDP,OT_HSSDP,OT_IPDP,OT_IRDP,OT_KNXDP,OT_MAPDP,OT_OCEANDP,OT_RFDP,OT_TIMERDP,OT_UPNPDP,OT_VARDP

LastChangeTimestampSeconds():
ReadOnly
Ergebnistyp: integer
anwendbar auf Object Classes: OT_ALARMDP,OT_CALENDARDP,OT_COMMDP,OT_DP,OT_HISTORYDP,OT_HSSDP,OT_IPDP,OT_IRDP,OT_KNXDP,OT_MAPDP,OT_OCEANDP,OT_RFDP,OT_TIMERDP,OT_UPNPDP,OT_VARDP

@Jens, wenns passig ist, bau ich das auch so ein

Black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Benutzeravatar
jmaus
Beiträge: 10265
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 519 Mal
Danksagung erhalten: 2181 Mal
Kontaktdaten:

Re: RFC: Neue LastChangeValue()/LastChangeTimestamp() Funktionen für DP in ReGa?

Beitrag von jmaus » 14.06.2023, 15:03

Black hat geschrieben:
13.06.2023, 18:10
[...]
nur kurz zum allgemeinen Abgleich
[...]
@Jens, wenns passig ist, bau ich das auch so ein
Sollte passen, ja.
RaspberryMatic 3.81.5.20250326 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Antworten

Zurück zu „RaspberryMatic“