Idee für verbesserte HmIP-Statusanzeige
Moderatoren: jmaus, Co-Administratoren
- jmaus
- Beiträge: 9844
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 462 Mal
- Danksagung erhalten: 1863 Mal
- Kontaktdaten:
Idee für verbesserte HmIP-Statusanzeige
Hallo Zusammen,
dieser Beitrag richtet sich vor allem an die die wissen wovon ich rede - hier allen voran Personen die bereits in der Entwicklungsmaterie drinstecken wie z.B. Baxxy oder jp112sdl.
Gerade eben - weil ich meine Zentrale selbst gerade mal neustarten musste - ist mir die Idee gekommen wie man denn die darstellung in der WebUI für homematicIP Geräte verbessern könnten die von der Zentrale noch nicht kontaktiert worden sind. Konkret geht es um das "Problem", das nach einem Neustart der Zentrale es ja einige Zeit (bis zu 1h) dauern kann bis der aktuelle Status von homematicIP Geräten in der WebUI mit dem Status übereinstimmt wie er in Wirklichkeit ist. Allen voran geht es hier z.B. um Schaltaktoren (HmIP-PSM) aber auch um die homematicIP basierten Fensterkontakte die Ihren Status ja in gewissen Zyklen bei der Zentrale abliefern. In der Praxis führt das mitunter dazu, das man ggf. etwas verwirrt ist wenn man frisch nach einem Neustart auf die WebUI schaut und für einen Schaltaktor den Status "Aus" dargestellt bekommt, jedoch das beim hinschauen auf den Schaltaktor aber nicht der fall ist und es einfach nur einige Minuten bis zu einer Stunde dauern kann bis der richtige Status dargestellt wird.
Um diese Verwirrung etwas zu reduzieren, kam mir gerade die Idee ob es nicht irgendwie möglich ist, herauszubekommen ob der Status eines Gerätes in der WebUI bzw. rfd/HmIPServer momentan quasi einfach "pending" ist und man sich gedulden müsste. Konkret schwebt mir da vor zu schauen ob die Kanäle des Gerätes über einen aktuellen Timestamp verfügen oder eben nicht. Hab das bis jetzt noch nicht weiter getestet, aber prinzipiell müsste es doch möglich sein einfach den LastTimeStamp() bzw. TimeStamp() Wert eines Kanales zu analysieren um herauszubekommen ob hier eine valide Zeit zu finden ist oder nicht.
Vielleicht könnte das mal jemand hier mit einer Testfarm kurz testen und berichten welche Timestamp-Werte nach einem frischen Reboot z.B. die Schaltkanäle von einem HmIP-PSM oder einem Fensterkontakt oder so haben und wie die konkret sich ändern sobald man dort eine Schaltung vornimmt. Denn wenn das so ist wie ich vermute, könnte man zumindest in der WebUI Geräteliste im Statuscolumn ggf. einfach eine Warnung oder ähnliches darstellen, das momentan noch kein aktueller Wert für diese Kanal bzw. dieses Gerät existiert..
Aber wie gesagt, das war jetzt einfach nur eine erste Idee um meine eigene anfängliche Verwirrung nach dem Zentralenneustart aufzulösen.
dieser Beitrag richtet sich vor allem an die die wissen wovon ich rede - hier allen voran Personen die bereits in der Entwicklungsmaterie drinstecken wie z.B. Baxxy oder jp112sdl.
Gerade eben - weil ich meine Zentrale selbst gerade mal neustarten musste - ist mir die Idee gekommen wie man denn die darstellung in der WebUI für homematicIP Geräte verbessern könnten die von der Zentrale noch nicht kontaktiert worden sind. Konkret geht es um das "Problem", das nach einem Neustart der Zentrale es ja einige Zeit (bis zu 1h) dauern kann bis der aktuelle Status von homematicIP Geräten in der WebUI mit dem Status übereinstimmt wie er in Wirklichkeit ist. Allen voran geht es hier z.B. um Schaltaktoren (HmIP-PSM) aber auch um die homematicIP basierten Fensterkontakte die Ihren Status ja in gewissen Zyklen bei der Zentrale abliefern. In der Praxis führt das mitunter dazu, das man ggf. etwas verwirrt ist wenn man frisch nach einem Neustart auf die WebUI schaut und für einen Schaltaktor den Status "Aus" dargestellt bekommt, jedoch das beim hinschauen auf den Schaltaktor aber nicht der fall ist und es einfach nur einige Minuten bis zu einer Stunde dauern kann bis der richtige Status dargestellt wird.
Um diese Verwirrung etwas zu reduzieren, kam mir gerade die Idee ob es nicht irgendwie möglich ist, herauszubekommen ob der Status eines Gerätes in der WebUI bzw. rfd/HmIPServer momentan quasi einfach "pending" ist und man sich gedulden müsste. Konkret schwebt mir da vor zu schauen ob die Kanäle des Gerätes über einen aktuellen Timestamp verfügen oder eben nicht. Hab das bis jetzt noch nicht weiter getestet, aber prinzipiell müsste es doch möglich sein einfach den LastTimeStamp() bzw. TimeStamp() Wert eines Kanales zu analysieren um herauszubekommen ob hier eine valide Zeit zu finden ist oder nicht.
Vielleicht könnte das mal jemand hier mit einer Testfarm kurz testen und berichten welche Timestamp-Werte nach einem frischen Reboot z.B. die Schaltkanäle von einem HmIP-PSM oder einem Fensterkontakt oder so haben und wie die konkret sich ändern sobald man dort eine Schaltung vornimmt. Denn wenn das so ist wie ich vermute, könnte man zumindest in der WebUI Geräteliste im Statuscolumn ggf. einfach eine Warnung oder ähnliches darstellen, das momentan noch kein aktueller Wert für diese Kanal bzw. dieses Gerät existiert..
Aber wie gesagt, das war jetzt einfach nur eine erste Idee um meine eigene anfängliche Verwirrung nach dem Zentralenneustart aufzulösen.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- Baxxy
- Beiträge: 10779
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 604 Mal
- Danksagung erhalten: 2205 Mal
Re: Idee für verbesserte HmIP-Statusanzeige
Aus dem Stehgreif heraus würde ich sagen das die Timestamps nach dem Reboot auf 1.1.1970 (oder so) stehen. Ob das bei allen Timestamps der Fall ist müsste ich prüfen.
Ich nutze das in Scripten wo 1.1.1970 zu "unbekannt" übersetzt wird.
Ich nutze das in Scripten wo 1.1.1970 zu "unbekannt" übersetzt wird.
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen
- jmaus
- Beiträge: 9844
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 462 Mal
- Danksagung erhalten: 1863 Mal
- Kontaktdaten:
Re: Idee für verbesserte HmIP-Statusanzeige
So wäre meine Idee, ja! Dann könnte man die Kanäle entsprechend farblich darstellen bzw mit einem marker versehen.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
- Baxxy
- Beiträge: 10779
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 604 Mal
- Danksagung erhalten: 2205 Mal
Re: Idee für verbesserte HmIP-Statusanzeige
Beispiel HmIP-PS
Kanal :2 - :5
LastDPActionTime auf Kanal:
ungeeignet
wird nur bei Änderungen der untergeordneten Datenpunkte aktualisiert, ist der Kanal beim Reboot real AUS wird der erst aktualisiert wenn der Kanal EINgeschalten wird
LastTimeStamp auf Datenpunkt:
ungeeignet
bekommt erst mit der 2. zykl. Übertragung einen korrekten Zeitstempel
TimeStamp auf Datenpunkt:
geeignet
steht nach Reboot auf "1970-01-01 01:00:00" und wird bei der ersten zykl. Übertragung aktualisiert
Bei einem HmIP-SWDx ist es genauso.
Mann müsste also den Timestamp von einem Datenpunkt der Statuskanäle als Indikator heranziehen. Idealerweise nimmt man STATE.
Grüße, Baxxy
Kanal :2 - :5
LastDPActionTime auf Kanal:
ungeeignet
wird nur bei Änderungen der untergeordneten Datenpunkte aktualisiert, ist der Kanal beim Reboot real AUS wird der erst aktualisiert wenn der Kanal EINgeschalten wird
LastTimeStamp auf Datenpunkt:
ungeeignet
bekommt erst mit der 2. zykl. Übertragung einen korrekten Zeitstempel
TimeStamp auf Datenpunkt:
geeignet
steht nach Reboot auf "1970-01-01 01:00:00" und wird bei der ersten zykl. Übertragung aktualisiert
Bei einem HmIP-SWDx ist es genauso.
Mann müsste also den Timestamp von einem Datenpunkt der Statuskanäle als Indikator heranziehen. Idealerweise nimmt man STATE.
Grüße, Baxxy
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
- Baxxy
- Beiträge: 10779
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 604 Mal
- Danksagung erhalten: 2205 Mal
Re: Idee für verbesserte HmIP-Statusanzeige
Na wenn dann für (fast) alle.
Beim SCo ist das Verhalten identisch zum SWDx. Auch hier kann der DP: STATE des Statuskanals zur Verifizierung genutzt werden.
Ob sich das für HM-Schaltaktoren "lohnt" weiß ich nicht. Werden die abgefragt oder stimmt der Status nach spätestens 3 Minuten?
Beim SCo ist das Verhalten identisch zum SWDx. Auch hier kann der DP: STATE des Statuskanals zur Verifizierung genutzt werden.
Ob sich das für HM-Schaltaktoren "lohnt" weiß ich nicht. Werden die abgefragt oder stimmt der Status nach spätestens 3 Minuten?
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: Idee für verbesserte HmIP-Statusanzeige
Alles was wach ist oder geweckt werden kann, wird abgefragt.
Die meisten Sensoren senden im 3min. Raster.
Optische Fensterkontakte brauchen länger (ca. 1h).
Magnetische am längsten? Weiß ich aber nicht genau.
Bei HM sind es also maximal die Fensterkontakte, bei denen der fehlende Status stört.
Schön wäre eine Option in Programmen, um das "bei geschlossen"-Triggern beim CCU Neustart zu unterbinden.
Oder 0°C bei Temperatursensoren (gut, da kann man mit der XML ein bisschen tricksen).
Aber es hat sich ja der "Anwesenheits-Variablen-Workaround" eingebürgert.
Ob man nun für diesen kurzen Zeitraum der fehlenden Daten extra eine Anzeige in der WebUI benötigt? Ich weiß nicht.
P.S.: Für BidCos fällt mir da gerade noch ein Lösung ein. Einen AskSin-X-Fach Aktor ohne physische Schaltausgänge.
Man verknüpft einfach jeden im Haus befindlichen Fensterkontakt zusätzlich mit einem Kanal dieses Aktors.
Die Schaltzustände werden ja beim Booten der CCU abgefragt und sie entsprechen auch während einer Downtime immer dem tatsächlichen Fensterstatus.
Die meisten Sensoren senden im 3min. Raster.
Optische Fensterkontakte brauchen länger (ca. 1h).
Magnetische am längsten? Weiß ich aber nicht genau.
Bei HM sind es also maximal die Fensterkontakte, bei denen der fehlende Status stört.
Schön wäre eine Option in Programmen, um das "bei geschlossen"-Triggern beim CCU Neustart zu unterbinden.
Oder 0°C bei Temperatursensoren (gut, da kann man mit der XML ein bisschen tricksen).
Aber es hat sich ja der "Anwesenheits-Variablen-Workaround" eingebürgert.
Ob man nun für diesen kurzen Zeitraum der fehlenden Daten extra eine Anzeige in der WebUI benötigt? Ich weiß nicht.
P.S.: Für BidCos fällt mir da gerade noch ein Lösung ein. Einen AskSin-X-Fach Aktor ohne physische Schaltausgänge.
Man verknüpft einfach jeden im Haus befindlichen Fensterkontakt zusätzlich mit einem Kanal dieses Aktors.
Die Schaltzustände werden ja beim Booten der CCU abgefragt und sie entsprechen auch während einer Downtime immer dem tatsächlichen Fensterstatus.
- Baxxy
- Beiträge: 10779
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 604 Mal
- Danksagung erhalten: 2205 Mal
Re: Idee für verbesserte HmIP-Statusanzeige
So'n Status-Dummy ist ne ziemlich coole Idee.
Für IP wird's das eher nicht geben und würde auch nichts bringen da sich die Aktoren nicht mit .State() aktiv abfragen lassen.
Auch wenn ich IP mag, manchmal schiele ich neidisch auf das gute alte HM-Zeugs (Display bei Heizkörper und Wandthermostat, Status-LED der HM-Schaltaktoren, Entscheidungswerte in Programmen, CS-Resistenz... )
Zurück zum Thema:
Die WebUI-Interna sind ja nicht so meins, aber es müsste doch möglich sein diese Prüfung nur für ausgewählte Geräte zu aktivieren.
Für IP wird's das eher nicht geben und würde auch nichts bringen da sich die Aktoren nicht mit .State() aktiv abfragen lassen.
Auch wenn ich IP mag, manchmal schiele ich neidisch auf das gute alte HM-Zeugs (Display bei Heizkörper und Wandthermostat, Status-LED der HM-Schaltaktoren, Entscheidungswerte in Programmen, CS-Resistenz... )
Was willst'e machen... < 15°C Aussentemperatur ist selbst im Hochsommer beim Zentralenstart immer WAHR.
Zurück zum Thema:
Die WebUI-Interna sind ja nicht so meins, aber es müsste doch möglich sein diese Prüfung nur für ausgewählte Geräte zu aktivieren.
-
- Beiträge: 235
- Registriert: 02.10.2018, 19:24
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 59 Mal
- Danksagung erhalten: 11 Mal
Re: Idee für verbesserte HmIP-Statusanzeige
ok, ich zähle mich grad net zu den "Wissenden", ne gewisse Erfahrung hab ich dennoch scho
Die Idee find ich schon mal
Besten Dank an an Jens + alle Unermüdlichen hier
Wenn ich mal meine 2ct beisteuern darf :
Ich denke fast, mit nem Check der Boot-Time gegen LastDPActionTime vom Channel = 0 der IP-Geräte könnte man feststellen, ob nach nem Reboot der aktuelle Status auch angezeigt ist.
btw, wie wäre es mit einer internen SV für Boot-Time ? Da könnte man so einiges mit "machen" :ergibt
Was meint Ihr ?
vG.
Die Idee find ich schon mal
Besten Dank an an Jens + alle Unermüdlichen hier
Wenn ich mal meine 2ct beisteuern darf :
- Ich habe mit restlichen HM-Geräten keine Probleme nach dem Reboot. Ist z.Zt noch HM-LC-Dim1T-DR und HM-LC-Sw1-DR. Die zeigen den Status korrekt an, d.h. wenn an, dann auch nachm reboot isses an im WebUI
- HMIP-Geräte sind nach dem Reboot erstmal definitiv aus = geschlossen... bis die sich melden oder eben geschaltet werden (manuell / Programm / DV)
- hab grad rebootet ... und festgestellt im SDV :
- Timestamp der IP-Geräte (channels + DPs) is erst mal "0"
- Sensoren wie Wetterstation, SLO, STHx funken nach 2-3 Minuten cyclic messages = 0,0
- BSM, BDT, BROLL u.a. senden eben weniger ...
- Timestamp des ch=0 (LastDPActionTime) bei IP-Geräten wird idR. aktualisiert bei manuellem Schalten und auch cycl. messages
- bei meinen HMIP-SMI isses anders : wenn die Bewegungsmeldung ausgeschaltet is, senden die NIX, werden aber nach Reboot als eingeschaltet dargestellt ... bis diese wieder eingeschaltet werden ... ok, evtl. special case
Code: Alles auswählen
HMIP-Gerät GeräteTyp cycl. cycCh cycUCh Rout. V-Lim. V-akt. RSSI_D RSSI_P LastActionTime CH=0
--------------------------------------------------------------------------------------------------------------------------------
__HmIP-ASIR HmIP-ASIR 1 2 12 0 3.3 4.3 196 0 1970-01-01 01:00:00
__HMIP-SWDO HMIP-SWDO 1 20 0 0 1.1 1.3 190 0 2022-05-25 22:40:20
_HmIP-RCV-50 HmIP-RCV-50 0 0 0 0 0.0 0.0 -1 -1 1970-01-01 01:00:00
_MP3P HmIP-MP3P 1 2 12 0 3.7 0.0 221 0 2022-05-25 22:42:31
Aussen Lichtsensor HmIP-SLO 1 0 0 0 2.4 2.8 197 0 2022-05-25 22:54:36
Aussen TempSensor HmIP-STHO 1 0 0 0 2.4 2.7 190 0 2022-05-25 22:55:22
Aussen Wetterstation HmIP-SWO-PR 1 0 0 0 3.2 0.0 195 0 2022-05-25 22:40:45
Briefkasten Klappe HMIP-SWDO 1 20 0 0 1.1 1.3 181 0 1970-01-01 01:00:00
Briefkasten Tuer HMIP-SWDO 1 20 0 0 1.1 0.0 0 0 1970-01-01 01:00:00
EG AZ BWM HmIP-SMI 0 20 1 0 2.2 2.6 198 0 1970-01-01 01:00:00
EG AZ Fenster HmIP-SWDM 1 20 0 0 2.2 0.0 0 0 1970-01-01 01:00:00
EG AZ Heizung HmIP-eTRV-2 1 2 13 0 2.2 0.0 0 0 1970-01-01 01:00:00
EG AZ Licht HmIP-BSM 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG AZ Rollo HmIP-BROLL 0 20 1 0 0.0 0.0 190 0 2022-05-25 22:51:23
EG Bad BWM HmIP-SMI 0 20 1 0 2.2 2.5 188 0 2022-05-25 22:51:58
EG Bad Dimmer HmIP-BDT 1 2 13 0 0.0 0.0 217 0 2022-05-25 22:40:51
EG Bad Fenster HMIP-SWDO 1 20 0 0 1.1 1.3 209 0 2022-05-25 22:48:37
EG Bad Heizung1 HMIP-eTRV 1 2 13 0 2.2 0.0 0 0 1970-01-01 01:00:00
EG Bad Wandthermostat HMIP-WTH 1 2 13 0 2.2 0.0 204 0 2022-05-25 22:45:13
EG Flur BWM HmIP-SMI 0 20 1 0 2.2 2.9 219 0 2022-05-25 22:42:27
EG Flur Haustuer HMIP-SWDO 1 20 0 0 1.1 1.1 * 208 0 2022-05-25 22:53:30
EG Flur Haustuerschloss HmIP-DLD 1 2 13 0 3.3 4.0 226 0 1970-01-01 01:00:00
EG Flur Licht Spiegel HmIP-BSM 1 2 13 0 0.0 0.0 214 0 2022-05-25 22:40:54
EG Flur Rauchmelder HmIP-SWSD 1 21 21 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG Flur Tuersprechanlage HmIP-PCBS2 1 2 12 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG Flur2 Licht HmIP-BSM 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG Kochen BWM HmIP-SMI 0 20 1 0 2.2 2.5 220 0 2022-05-25 22:41:37
EG Kochen Fenster HMIP-SWDO 1 20 0 0 1.1 1.2 203 0 1970-01-01 01:00:00
EG Kochen Heizung HMIP-eTRV 1 2 13 0 2.2 0.0 0 0 1970-01-01 01:00:00
EG Kochen Licht HmIP-BSM 1 2 13 0 0.0 0.0 218 0 1970-01-01 01:00:00
EG Kochen Licht Blende HMIP-PS 1 2 13 0 0.0 0.0 209 0 2022-05-25 22:45:50
EG Kochen Licht Schrank HMIP-PS 1 2 13 0 0.0 0.0 215 0 2022-05-25 22:45:49
EG Kochen Rollo HmIP-BROLL 0 20 1 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG Kochen Wassermelder HmIP-SWD 1 30 10 0 2.2 2.7 208 0 2022-05-25 22:54:11
EG SZ BWM HmIP-SMI 0 20 1 0 2.2 0.0 0 0 1970-01-01 01:00:00
EG SZ Fenster HmIP-SWDM-B2 1 20 0 0 2.2 0.0 0 0 1970-01-01 01:00:00
EG SZ Heizung HmIP-eTRV-B 1 2 13 0 2.2 2.3 198 0 1970-01-01 01:00:00
EG SZ Licht HmIP-BSL 1 2 13 0 0.0 0.0 208 0 2022-05-25 22:49:30
EG SZ Nachtlicht Bett HMIP-PS 1 2 13 0 0.0 0.0 201 0 1970-01-01 01:00:00
EG SZ Rauchmelder HmIP-SWSD 1 21 21 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG SZ Rollo HmIP-BROLL 0 20 1 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG SZ Schalter Bett HmIP-BRC2 0 20 0 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG WZ BWM HmIP-SMI 0 20 1 0 2.2 2.8 220 0 2022-05-25 22:46:36
EG WZ Fenster rechts HMIP-SWDO 1 20 0 0 1.1 1.3 207 0 1970-01-01 01:00:00
EG WZ Fenster vorn HMIP-SWDO 1 20 0 0 1.1 1.4 203 0 1970-01-01 01:00:00
EG WZ Heizung links HMIP-eTRV 1 2 13 0 2.2 2.4 211 0 2022-05-25 22:55:09
EG WZ Heizung rechts HMIP-eTRV 1 2 13 0 2.2 2.4 216 0 2022-05-25 22:55:11
EG WZ Licht Essen HmIP-BSM 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG WZ Licht Schrank HMIP-PS 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG WZ Licht Stehlampe HMIP-PSM 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG WZ Licht Vitrine HMIP-PS 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG WZ Rollo links HmIP-BROLL 0 20 1 0 0.0 0.0 205 0 1970-01-01 01:00:00
EG WZ Rollo rechts HmIP-BROLL 0 20 1 0 0.0 0.0 195 0 2022-05-25 22:34:10
EG WZ Rollo Tuer HmIP-BROLL 0 20 1 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG WZ Rollo vorn HmIP-BROLL 0 20 1 0 0.0 0.0 0 0 1970-01-01 01:00:00
EG WZ Tuer HmIP-SRH 1 2 13 0 1.1 1.3 207 0 2022-05-25 22:41:12
EG WZ Wandthermostat HMIP-WTH 1 2 13 0 2.2 2.6 212 0 2022-05-25 22:56:19
FB1 Garage HmIP-RCB1 0 20 0 0 1.1 0.0 0 0 1970-01-01 01:00:00
FB2 Garage HmIP-KRCA 0 20 0 0 1.1 0.0 0 0 1970-01-01 01:00:00
FB3 EG WZ HmIP-RC8 0 20 0 0 2.2 2.7 212 0 2022-05-25 22:47:13
KG AZ BWM HmIP-SMI 0 20 1 0 2.2 2.8 201 0 2022-05-25 22:50:09
KG AZ Fenster links HMIP-SWDO 1 20 0 0 1.1 1.3 188 0 1970-01-01 01:00:00
KG AZ Fenster rechts HMIP-SWDO 1 20 0 0 1.1 0.0 0 0 1970-01-01 01:00:00
KG AZ Garagentuer HMIP-SWDO 1 20 0 0 1.1 1.2 179 * 0 2022-05-25 22:56:05
KG AZ Heizung links HMIP-eTRV 1 2 13 0 2.2 0.0 0 0 1970-01-01 01:00:00
KG AZ Heizung rechts HMIP-eTRV 1 2 13 0 2.2 0.0 0 0 1970-01-01 01:00:00
KG AZ Licht PC HmIP-BSL 1 2 13 0 0.0 0.0 199 188 2022-05-25 22:54:24
KG AZ Licht Sofa HmIP-FSM 1 1 20 0 0.0 0.0 191 0 1970-01-01 01:00:00
KG AZ Nachtlicht HMIP-PS 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
KG AZ Rauchmelder HmIP-SWSD 1 21 21 0 0.0 0.0 0 0 1970-01-01 01:00:00
KG AZ Schalter1 HmIP-WRCC2 1 2 12 0 2.2 2.6 183 0 1970-01-01 01:00:00
KG AZ Schalter2 HMIP-WRC2 0 20 0 0 2.2 0.0 0 0 1970-01-01 01:00:00
KG AZ Schloss Garagentuer HmIP-DLD 1 2 13 0 3.3 0.0 0 0 1970-01-01 01:00:00
KG Bad BWM HmIP-SMI 0 20 1 0 2.2 2.5 204 0 2022-05-25 22:49:39
KG Bad Dimmer HmIP-BDT 1 2 13 0 0.0 0.0 204 0 2022-05-25 22:49:40
KG Bad Fenster HMIP-SWDO 1 20 0 0 1.1 0.0 0 0 1970-01-01 01:00:00
KG Bad Heizung HMIP-eTRV 1 2 13 0 2.2 2.5 205 0 1970-01-01 01:00:00
KG Bad Ventilator HmIP-BSM 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
KG Bad Wassermelder HmIP-SWD 1 30 10 0 2.2 2.7 191 0 1970-01-01 01:00:00
KG Flur BWM HmIP-SMI 0 20 1 0 2.2 2.8 189 0 2022-05-25 22:52:36
KG Flur Fenster HMIP-SWDO 1 20 0 0 1.1 1.2 197 0 1970-01-01 01:00:00
KG Flur Heizung HMIP-eTRV 1 2 13 0 2.2 0.0 0 0 1970-01-01 01:00:00
KG Flur2 BWM HmIP-SMI 0 20 1 0 2.2 2.8 199 0 2022-05-25 22:52:38
KG Flur2 Kellertuer HMIP-SWDO 1 20 0 0 1.1 1.3 176 * 0 1970-01-01 01:00:00
KG Flur2 Licht HmIP-BSM 1 2 13 0 0.0 0.0 207 0 2022-05-25 22:44:39
KG Garage BWM HmIP-SMI 0 20 1 0 2.2 2.9 175 * 0 2022-05-25 22:53:29
KG Garage Fenster links HMIP-SWDO 1 20 0 0 1.1 0.0 0 0 1970-01-01 01:00:00
KG Garage Fenster rechts HMIP-SWDO 1 20 0 0 1.1 1.2 175 * 0 2022-05-25 22:45:24
KG Garage Tor HMIP-SWDO 1 20 0 0 1.1 1.3 178 * 0 2022-05-25 22:46:53
KG Garage Tortaster HmIP-WGC 1 2 12 0 2.6 2.8 187 0 2022-05-25 22:46:34
KG Heizung Licht HmIP-BSM 1 2 13 0 0.0 0.0 196 0 1970-01-01 01:00:00
KG Keller Fenster HMIP-SWDO 1 20 0 0 1.1 1.3 182 0 2022-05-25 22:54:30
KG Keller Heizung HmIP-eTRV-B1 1 2 13 0 2.2 0.0 0 0 1970-01-01 01:00:00
KG Keller Licht HmIP-BSM 1 2 13 0 0.0 0.0 197 0 2022-05-25 22:45:04
KG Oellager Licht HmIP-BSM 1 1 20 1 0.0 0.0 0 0 1970-01-01 01:00:00
OG Flur Dachfenster HMIP-SWDO 1 20 0 0 1.1 0.0 0 0 1970-01-01 01:00:00
OG Flur Licht HmIP-BSM 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
OG Studio Licht HmIP-BSM 1 2 13 0 0.0 0.0 0 0 1970-01-01 01:00:00
OG Studio Rauchmelder HmIP-SWSD 1 21 21 0 0.0 0.0 0 0 1970-01-01 01:00:00
OG Studio Rollo Tuer HmIP-BROLL 0 20 1 0 0.0 0.0 201 191 2022-05-25 22:39:49
OG Studio Temperatur HmIP-STHD 1 3 1 0 2.2 2.6 206 0 1970-01-01 01:00:00
OG Studio Tuer HmIP-SRH 1 20 0 0 1.1 1.3 199 0 1970-01-01 01:00:00
btw, wie wäre es mit einer internen SV für Boot-Time ? Da könnte man so einiges mit "machen" :
Code: Alles auswählen
integer iTimeNow = localtime.ToInteger();
WriteLine("now : " # iTimeNow.ToTime().Format("%F %H:%M:%S"));
string stdOut;
system.Exec("cat /proc/uptime | cut -F1",&stdOut); !- get the boot time in sec from OS
integer secBoot = (0.5 + stdOut.ToFloat()).ToInteger(); !- round to Integer
integer iR; !- remaining sec
integer iDays = secBoot / (24*3600); iR = secBoot - (iDays*24*3600); !- calc. days since reboot + remaining
integer iHours = iR/ 3600; iR = iR - ( iHours*3600); !- calc. hours since reboot + remaining
integer iMin = iR / 60; !- calc. minutes since reboot
integer iSec = iR - (iMin*60); !- remaining seconds
time boottTime = (iTimeNow - secBoot).ToTime(); !- the REAL boot time
WriteLine("BootTime: " # boottTime);
WriteLine("up since: " # iDays # " days, " # iHours # "h, " # iMin # "min, " # iSec # "s");
Code: Alles auswählen
now : 2022-05-25 23:36:06
BootTime: 2022-05-25 22:23:00
up since: 0 days, 1h, 13min, 6s
vG.
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: Idee für verbesserte HmIP-Statusanzeige
Aber das ist ja kein Problem, wenn man das Programm im Fall des "CCU_IM_REBOOT"-Status nicht ausführen lässt.
Alternativ kann man halt auch an der XML was verändern, dass man statt 0° den min. (-40°C) oder max. (80°C) zurückgeben lässt.
Damit könnte man dann im Programm "WENN > -40 UND < 15 ..." nutzen. Ist nur nicht Update-fest.
... Möglichkeit, eigene Geräte zu integrieren
Was HmIP betrifft, da bin ich absolut leidenschaftslos. Da werd ich nichts mitentwickeln.