Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

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

Moderatoren: jmaus, Co-Administratoren

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

Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von jmaus » 11.07.2022, 12:34

Hallo Zusammen,

in letzter Zeit kam hier im Forum ja die prinzipielle Idee auf in der WebUI es mittels Auswertung des LastTimeStamp eines Kanales oder Gerätes ggf. zu ermöglichen in der WebUI eine Art "Status pending" Anzeige (oder ähnliches) umzusetzen. Hintergrund des ganzen ist ja, das nach einem frischen Neustart der CCU Zentrale es bei gewissen Geräten (z.B. Tür/Fensterkontakte, Schaltsteckdosen, etc.) nur der Default-Wert angezeigt wird und nicht der reelle Status (geöffnet/geschlossen) bis entweder die nächste Schaltoperation (Fenster auf/zu) passiert oder eine zyklische Statusmeldung erfolgt ist. Gerade seit breitem Einsatz von homematicIP Geräten ist hier im Forum wohl vermehrt verwirrung aufgekommen warum nach einem Neustart Geräte nicht den aktuellen Status wiedergeben, sondern mitunter erst nach 30 min bis zu einer Stunde, etc.

Um dem zu entgegnen kam wie gesagt die Idee auf, den Timestamp der letzten Aktion dieses Gerätes auszuwerten und falls dieser auf den 1.1.1970 fällt bzw. ".LastTimeStampSeconds() == 0" ist einfach anzunehmen das eben bis jetzt (d.h. seit dem CCU Start) noch keinerlei Kommunikation stattgefunden hat und damit der angezeigte Status eines Gerätes (offen/zu) eigentlich nicht repräsentativ ist und man eher von "unknown" als Status ausgehen muss.

Die letzten Tage habe ich mich nun ein bisschen damit beschäftigt mal zu schauen wie man das ganze vielleicht programmatisch umsetzen könnte. Gleich bei der ersten testweisen Umsetzung sind aber schon gewisse Fragen aufgekommen die ich erst einmal hier unter den "Experten" klären möchte bevor ich mich weiter an eine Umsetzung mache.

1. Im Prinzip ist es ja eigentlich ganz einfach in der WebUI einfach z.B. in der Spalte "Letzte Änderung" eine Art "Status pending" anzeige nur auf basis der ".LastTimeStampSeconds == 0" bedingung umzusetzen. Die kann z.B. einfach durch folgende Änderung testweise umgesetzt werden:

Code: Alles auswählen

--- /www/rega/pages/tabs/control/hdevichannels.htm.orig
+++ /www/rega/pages/tabs/control/hdevichannels.htm
@@ -248,8 +248,13 @@
             
             integer cId = chn.ID();
             string sLastTime = "";
+            integer iSeconds = -1;
             Call("/esp/system.fn::getLastTime()");
-            Write(sLastTime);
+            if(iSeconds <= 0) {
+              Write('<span style="background-color: #FFFF00;">STATUS&nbsp;PENDING</span>');
+            } else {
+              Write(sLastTime);
+            }
             
             Write("</span></td></tr>");
             Write( '<tr><td style="text-align:center;" class="CLASS03502">' );
Was mir hierbei dann jedoch gleich aufgefallen ist bzw. ersichtlich wurde, ist, das hier ja sämtlich Kanäle (auch die die nur Schaltaktionen zulassen und keinerlei Status anzeigen lassen) dauerhaft bis zur ersten Ausführung einer Aktion als "STATUS PENDING" ausgewiesen werden. Das kann/soll so ja nicht im Sinne des Erfinders sein.

2. Als zweiter Anlauf hab ich dann versucht eine Bedingung zu finden die das ganze besser eingrenzen lässt wann ein Gerät/Kanal vielleicht unter die Kategorie fällt das man diese "STATUS PENDING" Anzeige umsetzen kann. Und herausgekommen ist hierbei dies:

Code: Alles auswählen

--- /www/rega/pages/tabs/control/hdevichannels.htm.orig
+++ /www/rega/pages/tabs/control/hdevichannels.htm
@@ -248,8 +248,15 @@
             
             integer cId = chn.ID();
             string sLastTime = "";
+            integer iSeconds = -1;
             Call("/esp/system.fn::getLastTime()");
-            Write(sLastTime);
+            if(iSeconds <= 0) {
+              if(xmlrpc.GetParamsetDescription(chn.Interface(), chn.Address(), "MASTER").Find("<name>CYCLIC_INFO_MSG</name>") >= 0) {
+                Write('<span style="background-color: #FFFF00;">STATUS&nbsp;PENDING</span>');
+              }
+            } else {
+              Write(sLastTime);
+            }
             
             Write("</span></td></tr>");
             Write( '<tr><td style="text-align:center;" class="CLASS03502">' );
D.h. ich prüfe ob das MASTER Paramset des Kanales/Gerätes einen Eintrag "CYCLIC_INFO_MSG" besitzt und wenn ja, stelle ich dieses "STATUS PENDING" nur für dieses Gerät/Kanal dar.

Aber auch das hat gewisse Einschränkungen/Implikationen. So, hat ja nicht jeder Kanal - sondern nur der Kanal :0 eines Gerätes - diesesn CYCLIC_INFO_MSG ParamsetKey.

Die Frage ist also an die anderen Experten hier (z.B. @jp112sdl, @Baxxy, @Black, etc.) – und das ist hier eben kein Beitrag an die OttoNormalVerbraucher hier :) – ob es bzgl. dieser Umsetzung von eurer Seite noch gewisse Ideen gibt ob und wie man das ganze am besten Umsetzen könnte/sollte?!? Natürlich könnte man auch einfach nach nur gewissen Gerätetypen (z.B. nur die bekannten TFK) und Kanälen suchen und nur für diese dann das "STATUS PENDING" anwenden. Wenn möglich würde ich aber gerne hier eine allgemeingültige Lösung finden ohne das ganze auf nur gewisse Geräte/Kanäle zu beschränken. Die Frage wäre also: Gibt es irgendeine Kanal/Gerätekomponente mit der sich herausfinden lässt, das ein Kanal eines Gerätes (ggf. zyklische) Statusupdates bekommt und nicht nur Schaltoperationen zulässt?

Über entsprechendes Feedback/Input würde ich mich freuen, weil ich immer noch denke das solch eine zusätzliche Auswertung und Darstellung einer "Status pending" Anzeige sicherlich sehr hilfreich wäre und nicht nur etwas für die HomeAssistant Integration!

P.S:
Nur um zuviel Traffic hier im Beitrag zu vermeiden: Dieser Beitrag ist mit Absicht sehr technisch gehalten und explizit nur für die Mitglieder des Forums gedacht die wissen von was ich rede und die auch wissen wie man solch ein diff oben anwendet! :mrgreen:
RaspberryMatic 3.65.6.20220723 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

jp112sdl
Beiträge: 10661
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 705 Mal
Danksagung erhalten: 1689 Mal
Kontaktdaten:

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von jp112sdl » 11.07.2022, 12:57

Ich kann hier nur für das klassische BidCos schreiben.

CYCLIC_INFO_MSG gibt es nur bei den Geräten, bei denen man die "zyklischen Statusmitteilung" (de)konfigurieren kann (z.B. HM-Sec-SCo).
So hat z.B. ein Thermometer (WDS40-TH-I) diesen Parameter nicht.
jmaus hat geschrieben:
11.07.2022, 12:34
Was mir hierbei dann jedoch gleich aufgefallen ist bzw. ersichtlich wurde, ist, das hier ja sämtlich Kanäle (auch die die nur Schaltaktionen zulassen und keinerlei Status anzeigen lassen) dauerhaft bis zur ersten Ausführung einer Aktion als "STATUS PENDING" ausgewiesen werden. Das kann/soll so ja nicht im Sinne des Erfinders sein.
Sehe ich anders - wenn nur eine Meldung von Kanal 1 empfangen wurde, von Kanal 2 und 3 jedoch noch nicht, dann ist deren Status weiter "PENDING".

Der Status von Schaltaktoren wird beim Starten aktiv abgefragt.
Deren Zeitstempel sollte dann auch eigentlich nicht mehr 1.1.1970 sein? Ich kann es grad nicht testen

Bei BidCos könnte man über das Patchen der XML-Files in /firmware/rftypes noch einen PENDING-Status implantieren.
Hätte den Charme, dass direkt der Schnittstellenprozess diesen Status meldet.
Aber es hätte auch so einiges an Nacharbeiten an der WebUI zur Folge und wäre auch nur für BidCos anwendbar :-/

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

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

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von jmaus » 11.07.2022, 13:13

jp112sdl hat geschrieben:
11.07.2022, 12:57
CYCLIC_INFO_MSG gibt es nur bei den Geräten, bei denen man die "zyklischen Statusmitteilung" (de)konfigurieren kann (z.B. HM-Sec-SCo).
So hat z.B. ein Thermometer (WDS40-TH-I) diesen Parameter nicht.
Ok, das ist schonmal ein erstes gutes Feedback. Damit fällt meine erste Idee CYCLIC_INFO_MSG für eine Auswahl zu verwenden flach.
jp112sdl hat geschrieben:
11.07.2022, 12:57
jmaus hat geschrieben:
11.07.2022, 12:34
Was mir hierbei dann jedoch gleich aufgefallen ist bzw. ersichtlich wurde, ist, das hier ja sämtlich Kanäle (auch die die nur Schaltaktionen zulassen und keinerlei Status anzeigen lassen) dauerhaft bis zur ersten Ausführung einer Aktion als "STATUS PENDING" ausgewiesen werden. Das kann/soll so ja nicht im Sinne des Erfinders sein.
Sehe ich anders - wenn nur eine Meldung von Kanal 1 empfangen wurde, von Kanal 2 und 3 jedoch noch nicht, dann ist deren Status weiter "PENDING".
D.h. du würdest weiterhin dafür plädieren einfach nach "LastTimeStampSeconds() == 0" zu schauen und dann für alle diese den "Status pending" state anzunehmen?
jp112sdl hat geschrieben:
11.07.2022, 12:57
Der Status von Schaltaktoren wird beim Starten aktiv abgefragt.
Deren Zeitstempel sollte dann auch eigentlich nicht mehr 1.1.1970 sein? Ich kann es grad nicht testen
Viel mit reellen Aktoren/Geräten hab ich da ehrlich gesagt selbst noch nicht getestet. Ich sehe aber z.B. für die virtuellen HmIP-RCV/HM-RCV Taster das diese dauerhaft "STATUS PENDING" zeigen da dieser dauerhaft LastTimeStampSeconds()==0 haben solange da nicht aktiv selbst die SHORT oder LONG Taste gedrückt wird. Und was ist mit batteriebetriebenen Schaltaktoren? Mir fehlt da einfach momentan der globale Überblick über die gesamte Breite der BidCos/HmIP Geräte (inkl. der virtuellen) um einschätzen zu können ob eine einfache "LastTimeStampSeconds()==0" Auswertung pro Kanal bereits ausreicht um solch einen "Pending" State in der WebUI umzusetzen. Da wäre/bin ich einfach auf gewisse Hilfe von euch angewiesen um das Optimum rauszufinden, d.h. ob man einfach nach gewissen Gerätetypen prüft, oder gewisse rauslässt (z.B. die virtuellen) oder man eben eine gewisse Bedingung pro Kanal herausfinden könnte ob dieser einen Status überhaupt anzeigen/repräsentieren kann oder einfach nur ein einfacher Fire&Forget Kanal ist der auch keinen Status haben kann (wie eben die virtuellen Tasterkanäle). Fragen über Fragen :)
jp112sdl hat geschrieben:
11.07.2022, 12:57
Bei BidCos könnte man über das Patchen der XML-Files in /firmware/rftypes noch einen PENDING-Status implantieren.
Hätte den Charme, dass direkt der Schnittstellenprozess diesen Status meldet.
Aber es hätte auch so einiges an Nacharbeiten an der WebUI zur Folge und wäre auch nur für BidCos anwendbar :-/
Das würde ich erst einmal wirklich vermeiden wollen weil wir damit auch einfach weiter inkompatibeler zur Originalfirmware werden würden und das für die reine Darstellung in der WebUI nicht wirklich notwendig ist. Klar, wenn es der Schnittstellenprozess bereits melden könnte, würden auch externe Anwendungen (ioBroker, etc.) automatisch davon profitieren. Aber das würde ich erst einmal beiseite schieben wollen weil ich mir denke das müssen diese externen Applikationen ohnehin selbst teilweise umsetzen. D.h. wenn dann z.B. eine Smartphone-App wie pocketControl den pending status darstellen will, dann kann sie das ja auch prinzipiell einfach über "LastTimeStampSeconds()==0", wenn es denn so einfach ist und bleibt.
RaspberryMatic 3.65.6.20220723 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

jp112sdl
Beiträge: 10661
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 705 Mal
Danksagung erhalten: 1689 Mal
Kontaktdaten:

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von jp112sdl » 11.07.2022, 13:28

jmaus hat geschrieben:
11.07.2022, 13:13
D.h. du würdest weiterhin dafür plädieren einfach nach "LastTimeStampSeconds() == 0" zu schauen und dann für alle diese den "Status pending" state anzunehmen?
Ja, so würde ich es machen
jmaus hat geschrieben:
11.07.2022, 13:13
Ich sehe aber z.B. für die virtuellen HmIP-RCV/HM-RCV Taster das diese dauerhaft "STATUS PENDING" zeigen da dieser dauerhaft LastTimeStampSeconds()==0 haben solange da nicht aktiv selbst die SHORT oder LONG Taste gedrückt wird.
Das würde auch jede andere Funk-Fernbedienung betreffen.
jmaus hat geschrieben:
11.07.2022, 13:13
ob man einfach nach gewissen Gerätetypen prüft, oder gewisse rauslässt
Kanäle vom Typ "KEY" oder "VIRTUAL_KEY" würde ich aus der PENDING-Behandlung wohl ganz rausnehmen.
jmaus hat geschrieben:
11.07.2022, 13:13
einfach nur ein einfacher Fire&Forget Kanal ist der auch keinen Status haben kann (wie eben die virtuellen Tasterkanäle).
Genau - von denen wird ja in der WebUI nach einem Reboot auch kein "falscher" Status - sondern eben nur SHORT_/LONG_PRESS bei Betätigung - angezeigt.

jmaus hat geschrieben:
11.07.2022, 13:13
Klar, wenn es der Schnittstellenprozess bereits melden könnte, würden auch externe Anwendungen (ioBroker, etc.) automatisch davon profitieren.
Die Frage ist halt, ob sich der ganze Aufwand nur für die WebUI Anzeige lohnt.
Wie bei dem Patch für die "unsichtbaren UNREACH-Servicemeldungen" ist es dann halt nur in der WebUI sichtbar und von außen nicht wirklich zu verarbeiten.
Oder man baut noch interne Systemvariablen und Programme zu jedem Gerät, um den STATUS_PENDING weitergeben zu können. :D

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

MichaelN
Beiträge: 5837
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 442 Mal
Danksagung erhalten: 853 Mal

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von MichaelN » 11.07.2022, 13:42

Wenn am Ende nur eine Anzeige unter Status / Geräte rauskommt, fände ich das auch etwas enttäuschend.
Meine Erwartung wäre, daß man den Status "pending" auch in WebUI Programmen / Skripten abfragen kann, um entsprechend drauf zu reagieren. Sonst bin ich ja immer noch nicht weiter. Ziel muss es ja sein Automatismen zu stoppen, solange der Status unklar ist und nicht eine Anzeige zu haben, damit mir wieder einfällt, das ich gerade erst gebootet habe.

Für letzteres würde sogar eine globale Warnung in der Titelleiste reichen, die erst verschwindet wenn der letzte Kanal sich zurück gemeldet hat (und was ist mit Geräten die UNREACH sind)?
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

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

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von jmaus » 11.07.2022, 13:42

jp112sdl hat geschrieben:
11.07.2022, 13:28
jmaus hat geschrieben:
11.07.2022, 13:13
ob man einfach nach gewissen Gerätetypen prüft, oder gewisse rauslässt
Kanäle vom Typ "KEY" oder "VIRTUAL_KEY" würde ich aus der PENDING-Behandlung wohl ganz rausnehmen.
Ok, hast du vielleicht sogar im Kopf mit welcher Methode man diesen Typ bekommt in ReGa? Dann probier ich das gleich mal aus :)
jp112sdl hat geschrieben:
11.07.2022, 13:28
jmaus hat geschrieben:
11.07.2022, 13:13
Klar, wenn es der Schnittstellenprozess bereits melden könnte, würden auch externe Anwendungen (ioBroker, etc.) automatisch davon profitieren.
Die Frage ist halt, ob sich der ganze Aufwand nur für die WebUI Anzeige lohnt.
Wie bei dem Patch für die "unsichtbaren UNREACH-Servicemeldungen" ist es dann halt nur in der WebUI sichtbar und von außen nicht wirklich zu verarbeiten.
Oder man baut noch interne Systemvariablen und Programme zu jedem Gerät, um den STATUS_PENDING weitergeben zu können. :D
Prinzipiell bin ich ja bei dir, das auch das Ausblenden von Servicemeldungen am besten in den Schnittstellenprozessen aufgehoben gehört. Ist halt blos so eine Sache wenn der Hersteller noch prinzipiell mitmischt und man auch nicht vollen Quellcodezugriff zu allen Schnittstellenprozessen hat. Am Schluss würde das nämlich auch bedeuten das dann Entwickler fallunterscheidungen zwischen CCU3 und RaspberryMatic Firmware machen müssten bei den XMLRPC-/Schnittstellenabfragen und das ist eigentlich genau das was ich schon immer versuche zu vermeiden.
RaspberryMatic 3.65.6.20220723 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

jp112sdl
Beiträge: 10661
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 705 Mal
Danksagung erhalten: 1689 Mal
Kontaktdaten:

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von jp112sdl » 11.07.2022, 13:59

jmaus hat geschrieben:
11.07.2022, 13:42
Ok, hast du vielleicht sogar im Kopf mit welcher Methode man diesen Typ bekommt in ReGa? Dann probier ich das gleich mal aus :)
Das geht über channel.HssType()
So wie der Typ des Kanal 0 "MAINTENANCE" ist, so kann es auch einen Kanal XY vom Typ "KEY" oder "VIRTUAL_KEY" (oder wie im Link "KEY_TRANSCEIVER") geben:
https://github.com/eq-3/occu/blob/94d68 ... ns.fn#L359

Beim klassischen BidCos heißt der Kanaltyp "KEY"
https://github.com/AskSinPP/asksinpp-we ... rc.xml#L79

Möglicherweise heißt er bei HmIP ausnahmslos "KEY_TRANSCEIVER".

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

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

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von jmaus » 11.07.2022, 14:04

MichaelN hat geschrieben:
11.07.2022, 13:42
Wenn am Ende nur eine Anzeige unter Status / Geräte rauskommt, fände ich das auch etwas enttäuschend.
Meine Erwartung wäre, daß man den Status "pending" auch in WebUI Programmen / Skripten abfragen kann, um entsprechend drauf zu reagieren. Sonst bin ich ja immer noch nicht weiter. Ziel muss es ja sein Automatismen zu stoppen, solange der Status unklar ist und nicht eine Anzeige zu haben, damit mir wieder einfällt, das ich gerade erst gebootet habe.
Das könnte man vielleicht versuchen in einer weiteren Iteration umzusetzen. Im Grunde ist es ja (wenn es dabei bleibt) nur die Auswertung der LastTimeStampSeconds() Methode um herauszubekommen das ein aktueller Status existiert oder nicht. Jetzt läuft es aber erst einmal wirklich "nur" darauf hinaus eine gewisse Anzeige bzw. alternative Art der Darstellung zu haben um den Nutzer in der WebUI zu signalisieren das der Status eines Kanals gerade unbekannt ist.

Aber selbst dabei ist noch die Frage wie genau man das am besten in der WebUI nutzerfreundlich darstellt. Da hab ich auch noch keine geniale Idee dazu gehabt, ehrlich gesagt.
MichaelN hat geschrieben:
11.07.2022, 13:42
Für letzteres würde sogar eine globale Warnung in der Titelleiste reichen, die erst verschwindet wenn der letzte Kanal sich zurück gemeldet hat (und was ist mit Geräten die UNREACH sind)?
Ehrlich gesagt weiss ich nicht ob es überhaupt einen Zustand gibt das alle Kanäle aller Geräte nicht mehr PENDING sind. Es wird vmtl. immer irgendwo einen Kanal geben der Pending ist bis der Nutzer interaktiv diesen Kanal einmal schaltet. Aber ja, wenn es möglich wäre, würde ich auch ggf. darüber nachdenken auf der Hauptseite im Titel irgendeine Symbolik oder ähnliches darzustellen um klarzumachen, das es gewisse Geräte/Kanäle gibt deren aktueller Status noch "PENDING" ist. Wie genau das allerdings konkret nutzerfreundlich aussehen sollte, da müsste sich auch mal jemand einen Gedanken und Vorschläge dazu machen :)
RaspberryMatic 3.65.6.20220723 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

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

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von jmaus » 11.07.2022, 14:16

jp112sdl hat geschrieben:
11.07.2022, 13:59
Das geht über channel.HssType()
So wie der Typ des Kanal 0 "MAINTENANCE" ist, so kann es auch einen Kanal XY vom Typ "KEY" oder "VIRTUAL_KEY" (oder wie im Link "KEY_TRANSCEIVER") geben:
https://github.com/eq-3/occu/blob/94d68 ... ns.fn#L359

Beim klassischen BidCos heißt der Kanaltyp "KEY"
https://github.com/AskSinPP/asksinpp-we ... rc.xml#L79

Möglicherweise heißt er bei HmIP ausnahmslos "KEY_TRANSCEIVER".
Ok, das würde dann nach aktuellem Stand bedeuten das die Änderung wie folgt aussehen würde:

Code: Alles auswählen

--- /www/rega/pages/tabs/control/hdevichannels.htm.orig
+++ /www/rega/pages/tabs/control/hdevichannels.htm
@@ -248,8 +248,16 @@
             
             integer cId = chn.ID();
             string sLastTime = "";
+            integer iSeconds = -1;
             Call("/esp/system.fn::getLastTime()");
-            Write(sLastTime);
+            if(iSeconds <= 0) {
+              string cType = chn.HssType();
+              if((cType != "VIRTUAL_KEY") && (cType != "KEY_TRANSCEIVER") && (cType != "KEY") && (cType != "SYSTEM")) {
+                Write('<span style="background-color: #FFFF00;">STATUS&nbsp;PENDING</span>');
+              }
+            } else {
+              Write(sLastTime);
+            }
             
             Write("</span></td></tr>");
             Write( '<tr><td style="text-align:center;" class="CLASS03502">' );
Wer kann und mag kann es so ja mal selbst mit vielen Gerätetypen, etc. austesten um zu sehen ob das dem entspricht was man erwarten würde.
RaspberryMatic 3.65.6.20220723 @ Proxmox – ~195 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker – GitHub / Twitter / Facebook / Sponsors

Benutzeravatar
stan23
Beiträge: 1924
Registriert: 13.12.2016, 21:14
System: Alternative CCU (auf Basis OCCU)
Wohnort: Altmühltal
Hat sich bedankt: 491 Mal
Danksagung erhalten: 296 Mal
Kontaktdaten:

Re: Mögliche "STATUS PENDING" Anzeige in WebUI. Feedback erbeten.

Beitrag von stan23 » 11.07.2022, 15:23

Sieht ganz nett aus :)
HM_STATUS_PENDING.png
HM_STATUS_PENDING.png (10.68 KiB) 415 mal betrachtet

EDIT:
Zum Thema "letzte Änderung":
wenn ein Schaltaktor (HmIP-PSM, HM-ES-PMSw1-Pl) oder ein Wandthermostat (HM-TC-IT-WM-W-EU) den gleichen Schaltzustand oder die gleiche gemessene Temperatur meldet, dann ist es doch keine Änderung und das gelbe Schild bleibt bestehen?
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

Antworten

Zurück zu „RaspberryMatic“