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

[jp112sdl]

Als Beispiel sei hier mal mein HM-Sen-MDIR-WM55 mit "MOTION" genannt der 24h nicht bewegendes zu melden hatte und damit die ganze Zeit "unknown" bzw. im "STATUS PENDING" war.

Tja, da muss man sich nun entscheiden, ob man den STATUS PENDING halt konsequent eingeblendet.
Rein technisch ist es ja korrekt.
Die CCU hat nix empfangen. Also ist auch kein gültiger Status vorhanden. Und wenn sich ein halbes Jahr nichts bewegt, dann steht das dort eben so lange.

Oder die Liste muss noch um die Kanäle erweitert werden, die keine Status haben können.
viewtopic.php?f=65&t=74790#p724702
MOTION ist ja nur ein Impuls, wie ein Tastendruck einer Fernbedienung (KEY, was bisher schon aus der STATUS PENDING Behandlung rausfällt).

Ggf. ist eine Whitelist hier besser als eine Blacklist.

[Baxxy]

Tja, da muss man sich nun entscheiden, ob man den STATUS PENDING halt konsequent eingeblendet.
Rein technisch ist es ja korrekt.

Sehe ich auch so.
Und da die WebUI ja mehr "Verwaltungsoberfläche" als "Visualisierung" ist hätte ich kein Problem damit dort bei manchen Geräten längerfristig ein "STATUS PENDING" zu sehen.

Ich habe jetzt auf meinem Testsystem die Vorlage von Jens drin, mit erweiterter "Blacklist" (mit einer Whitelist bin ich nicht klargekommen) und das sieht für meinen Geräte-Zoo (primär IP) soweit ganz gut aus. Kleine Inkonsistenzen gibts's noch... mal schauen.

Blacklist (mit WRCD für Micha )

Code: Alles auswählen

if((cType != "VIRTUAL_KEY") && (cType != "KEY_TRANSCEIVER") && (cType != "KEY") && (cType != "SYSTEM") && (cType != "SWITCH_VIRTUAL_RECEIVER") && (cType != "SWITCH_WEEK_PROFILE") && (cType != "ACOUSTIC_DISPLAY_RECEIVER")) {

Edit:
Der HM-Sen-MDIR-WM55 mit "MOTION" war schlecht getestet.
Macht man Licht in der Dunkelkammer an (ohne erfasst zu werden) reicht die Änderung der "Helligkeit" um "STATUS PENDING" verschwinden zu lassen. Sollte passen.

[MichaelN]

mit erweiterter "Blacklist"

gerade auf meinem vor 4 Tagen gestarteten System getestet

"falsche" Pending-Meldungen gibt es noch bei:

BROLL - die nicht genutzten Kanäle 5&6 (SHUTTER_VIRTUAL_RECEIVER), das Wochenprogramm auf Kanal 7 (BLIND_WEEK_PROFILE)
HM-WDS30-OT2-SM-2 - Kanal 5 - HSS-Type WEATHER (wie die anderen) - wobei ich gar nicht weiß, was der Kanal 5 für eine Funktion hat

[Baxxy]

Alles klar.
"BLIND_WEEK_PROFILE" kann definitiv in die Blacklist
"SHUTTER_VIRTUAL_RECEIVER" betrifft dann aber alle 3 (virtuellen Kanäle), wenn hier der Statuskanal ("SHUTTER_TRANSMITTER") als Indikator ausreicht... wäre ja wie bei den PS/PSM. Ich nehm's mal in die Blacklist auf.

Bei "WEATHER" bin ich unentschlossen.
Das beträfe wohl viele HM-Geräte, wobei die ja eigentlich i.d.R. in recht kurzen Abständen senden. Was da dein Kanal:5 für ne Funktion hat weiß ich auch nicht, die Datenpunkt-Doku ist da nicht gerade auskunftsfreudig.

Aktualisierte Blacklist:

Code: Alles auswählen

if((cType != "VIRTUAL_KEY") && (cType != "KEY_TRANSCEIVER") && (cType != "KEY") && (cType != "SYSTEM") && (cType != "SWITCH_VIRTUAL_RECEIVER") && (cType != "SWITCH_WEEK_PROFILE") && (cType != "ACOUSTIC_DISPLAY_RECEIVER") && (cType != "BLIND_WEEK_PROFILE") && (cType != "SHUTTER_TRANSMITTER")) {

[MichaelN]

Ja, ich würde WEATHER auch nicht in die Blacklist mit aufnehmen - gerade bei Temperaturen möchte man ja wissen, ob sie aktuell sind. Auch wenn das meist nur 3 Minuten dauert. Ich meine mich schwach zu erinnern, das Kanal 5 für die Kommunikation mit der Wetterstation gedacht ist???

[jp112sdl]

wobei ich gar nicht weiß, was der Kanal 5 für eine Funktion hat

Verknüpfung mit Geräten, die Temperatursensoren als Verknüpfungspartner unterstützen.
Die Anzahl an Geräten, die als Link target den Typ WEATHER_T unterstützen, ist recht übersichtlich (Istwertgeber eines HM-CC-RT-DN oder für die Anzeige am HM-WDC7000)

[Baxxy]

Istwertgeber eines HM-CC-RT-DN

Na das fetzt ja.
Da kann man sich das Wandthermostat sparen?
Geht bei IP nicht mehr, zumindest habe ich keine passenden Partner gefunden.

[jp112sdl]

Da kann man sich das Wandthermostat sparen?

Wenn man keinen Wert auf Luftfeuchtemessung, Display und Bedienmöglichkeit legt - ja.


Hier mal eine Liste der Kanaltypen der BidCos-Geräte, die keinen zyklischen Status senden und die nicht netzbetrieben oder per BURST weckbar sind (bei denen beim CCU Start der Status also nicht aktiv abgefragt wird)

Code: Alles auswählen

KEY
MOD_EM8BIT_TRANSMITTER
MOTION_DETECTOR
PULSE_SENSOR
SWITCH_INTERFACE

Wobei ich jedoch nicht weiß, ob z.B. bei der HM-RC-19, die zwar BURST unterstützt, alle Kanäle auch bei einem CCU Start abgefragt werden.
Falls nicht, kommen noch zwei hinzu:

Code: Alles auswählen

CENTRAL_KEY
DISPLAY

[Baxxy]

Damit wären wir inzwischen bei "The Blacklist - Staffel 9" ...

"KEY" hatten wir schon, aber bei einigen anderen wäre die Frage ob es sinnvoll ist das "Config Pending" per se wegzulassen oder es anzuzeigen bis ein korrekter Status empfangen wurde. Wobei hier wieder fraglich wäre ob es von ReportValueUsage() abhängt.

Ich kenne und habe die Teile alle nicht daher bin ich unschlüssig.
"SWITCH_INTERFACE" z.B. könnte dann wie gewohnt ewig einen falschen Status (ohne Hinweis) anzeigen.

[jp112sdl]

Damit wären wir inzwischen bei "The Blacklist - Staffel 9" ...

Die ganzen Dinger aus dem Homebrew Bereich sind da noch gar nicht berücksichtigt.

"SWITCH_INTERFACE" z.B. könnte dann wie gewohnt ewig einen falschen Status (ohne Hinweis) anzeigen.

Ja, die Meldung ist dann vielleicht nervig.

Aber wenn der Kontakt "ewig" offen ist, nach dem Reboot der CCU in der WebUI aber default "geschlossen" angezeigt wird, dann ist der Hinweis STATUS_PENDING schon ok.

Keine Ahnung ob man (Jens) sich hier nur ein neue Baustelle schafft.

Mich persönlich wird die Meldung STATUS_PENDING eher stören, aber die ist ja schnell wieder rausgepatcht. Ich kenne das CCU Verhalten an der Stelle und bin mir der Sache bewusst, dass der Zustand evtl. falsch ist, so lange kein Änderungszeitstempel existiert. Das reicht mir aus.