Test Adapter Device-Watcher v2.x.x GitHub/Latest

[Hiltex]

@jb_sullivan ich bin nicht so der Freund davon, Formatierungen hart im Code zu hinterlegen. Stattdessen würde ich vorschlagen, an die HTML-Elemente CSS-Klassen anzuhängen, die dann jeder formatieren kann, wie er mag und dass es auch in das Gesamtbild der Visu passt. Das wird auf jeden Fall mit allen HTML-Basierten Visualisierungen funktionieren.

Beim Batteriestand könnte man zum Beispiel den Grenzwert aus den Instanzeinstellungen verwenden, um an die ganze Tabellenzeile (!) die Klasse „BatteryLow“ anzuhängen, bei online/offline-Tabellen hängt man die Klasse „offline“ an, usw.

@ciddi89 Wenn das für dich interessant klingt, dann schau dir mal den Sonos-Adapter im Latest an. Dort hab ich in der html-Queue das genau so eingebaut. Der Unterschied ist nur, dass für die Änderung vom aktuellen Track eine andere Funktion tätig ist, weil die Grundstruktur des Adapters das erforderlich machte. Das wird bei dir aber vermutlich nicht zutreffen.

[JB_Sullivan]

@da_woody sagte in Test Adapter Device-Watcher v2.x.x GitHub/Latest:

nette idea, bin mir nur nicht sicher, was das dann in z.b. iQontrol, oder anderen visus anrichtet... nicht jeder verwendet VIS...

Dann gibt man bei anderen Visualisierungen in den Instanzfeldern nichts ein. Die Felder in der Instanzeinstellungen würde man nur ausfüllen wenn es für jeden persönlich einen Mehrwert darstellen. Sonst läßt man die Felder halt leer.

@ciddi89 Meine CSS Kenntnisse sind leider nicht dafür ausreichend, das ich mir z.B. deinen device-watcher.0.listAll Datenpunkt so formatieren kann, das dieser immer wieder automatisert die "richtigen" Farben einstellt.

Grafana wäre an der Stelle für mich keine Alternative.

[A Former User]

@jb_sullivan normalerweise sollte man einen einfachen override pro Spalte festlegen können. Vielleicht ist hier einer dabei der sich damit auskennt und der Doku eine Anleitung darüber spendieren kann. Ansonsten muss ich mich mal damit beschäftigen ob das in VIS überhaupt möglich ist. Aber denke schon. Ansonsten ja GitHub -> Feature request wenn das mit den Instanzen usw. Dann alles wunschgemäß läuft kann ich mich darum kümmern.

@Hiltex danke für die Info schau ich mir mal an bei Gelegenheit. Ist immer gut zu wissen wie andere ähnliche Sachen abwickeln in ihren Code

[da_Woody]

@ciddi89 sagte in Test Adapter Device-Watcher v2.x.x GitHub/Latest:

I'm sorry about that.

ok, pfad anpassen. klappert. allerdings:


definitiv mehr als 2...

edith:
ist mir zwar schnuppe, hab das ja eh in iQontrol drinnen.

[JB_Sullivan]

Wenn das mit den Farben zu aufwändig ist, vielleicht könnten man ja eine eigene Liste erstellen, in der nur die ONLINE Geräte auftauchen. Es gibt zwar eine Gesamtliste und eine Offline Liste, aber keine für alle Geräte die Online sind.

Wäre das ggf. möglich?

[A Former User]

@jb_sullivan das mit der zusätzlichen Liste ist machbar. Das andere muss ich mal schauen. Wenn ich bisschen mehr Zeit habe will ich erst in VIS prüfen ob das auch so geht und wenn ja werde ich das Dokumentieren. Das würde jede menge Code & Ressourcen im Adapter sparen davon mal abgesehen weiss ich garnicht ob jede Visualisierung damit um kann wenn ich CSS Daten mit in JSON pflücke.

[Rookie50]

@ciddi89 Hi, ich habe noch 13 HM-CC-RT-DN Thermostate und bekomme für Diese nur den Battery Status "OK" anstatt den Wert der Batteriespannung. Kannst Du für diese Geräte noch den DP hm-rpc.0.XXXXXX.4.BATTERY_STATE abfragen? Dort bekommt man den Wert in Volt:

{
  "type": "state",
  "common": {
    "name": "Heizung Kueche:Thermostat Sender.BATTERY_STATE",
    "def": 0,
    "type": "number",
    "read": true,
    "write": false,
    "min": 1.5,
    "max": 4.6,
    "unit": "V",
    "role": "value.voltage"
  },
  "native": {
    "CONTROL": "NONE",
    "DEFAULT": 0,
    "FLAGS": 1,
    "ID": "BATTERY_STATE",
    "MAX": 4.6,
    "MIN": 1.5,
    "OPERATIONS": 5,
    "TAB_ORDER": 2,
    "TYPE": "FLOAT",
    "UNIT": "V"
  },
  "from": "system.adapter.hm-rega.0",
  "user": "system.user.admin",
  "ts": 1674480654483,
  "_id": "hm-rpc.0.XXXXXXXXXX.4.BATTERY_STATE",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Ich habe auch ein Github issue geöffnet.

Gruß Robert

[A Former User]

@rookie50 hab dein issue schon gesehen. Wird in den nächsten Tagen irgendwann mit aufgenommen.

[Rookie50]

@ciddi89 ich hätte da noch eine Idee, um große Listen übersichtlicher zu machen. Ich würde mir wünschen, wenn man die Listen noch in die Funktion (oder Gewerke) unterteilen könnte. Also z.B. Thermostate, Fenter/Tür Kontakte, usw.

[A Former User]

@rookie50 am besten ist es wenn ihr ein Feature request auf GitHub stellt. Hier gehen solche Anfragen/Ideen mit der Zeit unter, da ich mir manchmal auch Zeit lasse mit dem antworten um zu überlegen ob es auch Sinn macht und nicht zu viel wird.
Wer möchte kann dann bei Feature request die Anfragen mit einen Emoji versehen dann sehe ich auch das mehrere Interesse an sowas haben. Das macht dann die Entscheidung einfacher.

[JB_Sullivan]

Frage zu der neuen Instanz Überwachung - welcher Datenpunkt ist für den Instanz Status zuständig? evt. alive DP der Systemdatenpunkte der entsprechenden Adapter?

Wenn ja, wird das u.a. bei dem NUKI Extended Adapter und bei dem innogy-smarthome Adapter nicht korrekt ausgewertet.

Beide Adapter sind in der Device Watcher Liste als "not connected to Device" gekennzeichnet, obwohl beiden Adapter grün sind und ihre System Datenpunkte ein "alive = true" ausgeben.

...... oder wird ggf. einen anderen Datenpunkt ausgewertet?

[A Former User]

@jb_sullivan am besten die GitHub version mal installieren, also über die Katze und bei benutzerdefiniert den link einfügen. Hab in den letzten Tagen bezüglich der Instanzüberwachung diverse Verbesserungen gemacht.
Aber ja über den alive Datenpunkt wird festgestellt ob der Adapter läuft oder nicht.

[JB_Sullivan]

@ciddi89 sieht sehr gut aus - das was ich eben gerade aus dem GIT installiert habe, zeigt mir nun auch noch ein paar mehr Adapter an, die vorher noch gar nicht erfasst wurden (zuvor 36 - jetzt die reale Zahl von 55 Instanzen).

Auch die Stati der beiden zuvor genannten Instanzen passen nun zu dem alive DP. Von meiner Seite also erstmal bzgl. der Instanz Auswertung.

[da_Woody]

@ciddi89 na, knapp vorbei ist auch daneben...

[A Former User]

@da_woody derzeit werden nur schedule und daemon adapter unterstützt. Evtl. sind das zwei vom anderen typ?

[da_Woody]

@ciddi89 muss mal linsen...

[A Former User]

@da_woody du nutzt doch vis material design oder? wenn ja dann ist das einer von den zwei. Der ist nämlich Mode 'once'

[Rushmed]

@ciddi89 Danke für die tolle Arbeit!

Ich schaffe es nicht mit den ioBroker onboard Mitteln die Anzahl der Fehler und Warnings aus dem Log darzustellen.
Kann man das vll. in den Adapter integrieren?

[A Former User]

@rushmed das was du suchst macht der logparser wenn du regelmässig die jsons resetest hast du auch immer die aktuelle Anzahl.

[da_Woody]

@ciddi89 nix da. ich bin mit iQontrol unterwegs.
aber egal, in den objekten passts ja nicht.
ich schau mir das morgen an, wo das prob ist.
hunger und müde...