Test Adapter iQontrol 2.0.x Vis (Entwicklungs-Thread)

[s.bormann]

@mucki sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann
Das scheint die Unterschiede zwischen Homematic und nicht Homematic Thermostate zu erklären.

Kann es aber sein, dass Homematic IP hier noch einmal anders gestrickt ist? Ich habe diverse Homematic IP Heizkörperthermostate und zusätzlich IP Wandthermostate.

Folgende Problematik erfahre ich bei beiden (Beispiel anhand Wandthermostat HMIP-WTH-2):

1. es gibt kein Objekt „AUTO_MODE“ -> um zwischen Auto und Manuell umzuschalten, kann man CONTROL_MODE direkt auf 0 oder 1 setzen (funktioniert).
2. Boost und Party Modus muss man in der Tat am eigenen Objekt auf True setzen. CONTROL_MODE auf 2 oder 3 zu setzen hat keine Auswirkungen.

Wenn ich die bisherigen Angaben richtig verstanden habe ist somit weder die Geräteklasse Thermostat noch die Geräteklasse Thermostat-Homematic die richtige, oder habe ich einen Denkfehler?

Oha, jetzt wird es also richtig komplex. Normale Thermostate, HM-Thermostate und HMIP-Thermostate unterscheiden sich alle UND sie unterscheiden sich noch mal, wenn sie über FHEM eingebunden werden
Werde mich mal mit folgender Lösung beschäftigen:
iQontrol beschreibt den Datenpunkt CONTROL_MODE, es sei denn, es findet einen eigenen Datenpunkt für AUTO_MODE, MANU_MODE etc..., dann beschreibt es eben diesen Datenpunkt. Das könnte dann etwas universeller sein...

[s.bormann]

@mucki sagte in [Neuer Adapter] Visualisierung iQontrol:

@dslraser
Wahrscheinlich ist es derzeit für Homematic IP Besitzer das einfachste, die Heizkörperthermostate als „Thermostat“ einzubinden (inklusive Wahlmöglichkeit zwischen Auto und Manuell).
Für relevante Stellen kann man dann ja noch einen Schalter für die Boostfunktion anlegen...

Wartet mal ab, ich versuche das zu verbessern.

[dslraser]

@s-bormann sagte in [Neuer Adapter] Visualisierung iQontrol:

@blackeagle998 sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann sagte in [Neuer Adapter] Visualisierung iQontrol:

Hallo,
meia24 hat auf Github berichtet, dass es bei Jalousien blöd ist, dass der Wert beim Verschieben des Schiebereglers so oft aktualisiert, d.h. gesendet wird. Finde ich auch nachvollziehbar. Siehe:
https://github.com/sbormann/ioBroker.iqontrol/issues/79

Deshalb jetzt die Frage an alle: Welche Lösung ist besser?

• Senden nur beim Loslassen des Reglers oder
• Senden weniger häufig (z.B. alle 2 Sekunden) beim Verschieben des Reglers

Wie ist Eure Meinung?

Beim Dimmen einer Lampe macht es schon Sinn, das sofort zu sehen.
Bei den Rollläden sehe ich "beim Loslassen" als sinnvollste Lösung.

Sehe ich auch so. Gibt es andere Meinungen?

Bei Heizungsventilen/Thermostaten macht es erst nach dem loslassen Sinn, finde ich. (dort wird anscheinend auch direkt beim schieben geregelt, zu mindestens sieht es so aus und das verusacht dann direkt mehrere Sendebefehle, Stichwort DutyCycle ?)

Licht finde ich direkt bei jeder Änderung besser.

[mucki]

@s-bormann
Vielen Dank für deine Hilfe!

Min/Max ist meines Erachtens gesetzt. Anbei Screenshots:

[mucki]

@s-bormann
Das wäre der Knaller.
Vielen Dank für dein Engagement!

[dslraser]

@mucki
warum steht da 0:Fehler und 1:okay ?

[mucki]

@dslraser
Das sind die möglichen Stati des Objektes.
1:Okay -> Batterie ist i.O.
0:Fehler -> Batterie ist Fritten

(Prozentuale Anzeige gibt es leider nicht)

[mucki]

@dslraser
Könnte auch noch das RAW liefern:
P.S.: Invert steht hier auf false -> war nur ein Test -> Batteriesymbol bleibt unverändert...

{
  "from": "system.adapter.lupusec.0",
  "ts": 1547832316999,
  "common": {
    "name": "EG Bad Fenster (Batterie)",
    "type": "number",
    "role": "value",
    "states": "0:Fehler;1:Okay",
    "min": 0,
    "max": 1,
    "read": true,
    "write": false,
    "custom": {
      "iqontrol.0": {
        "enabled": true,
        "readonly": true,
        "invert": false,
        "confirm": false,
        "unit": "",
        "unit_zero": "",
        "unit_one": "",
        "min": 0,
        "max": 1,
        "step": "",
        "type": "number",
        "role": "",
        "targetValueId": "",
        "states": {
          "0": "0",
          "1": ":",
          "2": "F",
          "3": "e",
          "4": "h",
          "5": "l",
          "6": "e",
          "7": "r",
          "8": ";",
          "9": "1",
          "10": ":",
          "11": "O",
          "12": "k",
          "13": "a",
          "14": "y"
        }
      }
    },
    "icon": "/icons/4.png"
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "lupusec.0.devices.RF:70cea110.battery_ok",
  "type": "state"
}

[dslraser]

@mucki
ich habe gerade gesucht wie man den "tatsächlichen" Typ ermittelt.
Das hier hat @paul53 mal dazu geschrieben.

https://forum.iobroker.net/post/290440

[dslraser]

@mucki
ehrlich gesagt kapiere ich diesen RAW nicht und habe ich so auch noch nicht gesehen (ich habe aber auch dieses Gerät nicht). Eine Werteliste sieht bei mir auch anders aus.
Vielleicht kann @s-bormann dazu mehr sagen.

[mucki]

@dslraser
Das war ja das RAW, nachdem ich über den Schlüssel von iQontrol Änderungen (Invert etc.) vorgenommen habe.

Anbei noch ein RAW von einem "unangetasteten" weiteren Kontakt:

{
  "from": "system.adapter.lupusec.0",
  "ts": 1547832316930,
  "common": {
    "name": "KG Waschraum Kellertür (Batterie)",
    "type": "number",
    "role": "value",
    "states": "0:Fehler;1:Okay",
    "min": 0,
    "max": 1,
    "read": true,
    "write": false,
    "icon": "/icons/4.png"
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "lupusec.0.devices.RF:0bbea110.battery_ok",
  "type": "state"
}

[dslraser]

@mucki
Du hast ja auch andere Geräte (z.B. HMIP) und da sehen die RAW anders aus, zumindestens was die Schreibweise der states angeht. Also unter min und max ist open(1) und close(0) usw. anders.(Werteliste)
zum Vergleich

[DocGame]

@mucki
1 Tag, nachdem ich das mit dem Nuki geschrieben habe ist mein Nuc (ohne vernünftige Sicherung) komplett abgeraucht.
Ich habe jetzt fast eine Woch mit dem Aufsetzen auf einem neuen Win10-Nuc verbracht(über 200 Geräte verschiedenster Hersteller/Systeme) wollen erstmal eingebunden sein. Die ganzen Blocklys usw. neu zu schreiben dauert leider auch ewig.
Ich hoffe, ich komme die nächsten Tage dazu. Das Problem ist, das ich unter dem Dach am PC sitze und das Nuki 3 Stockwerke darunter. Es liefert so viele States, das ich noch nicht recht durchblicke welcher genau was bedeutet. wenn ich zb. über das Keypad öffne ist es so eingestellt, dass die Klinke (oder wie das Teil heißt) 3 Sekunden ganz zurückgeht und die Tür ist dann nicht nur aufgeschlossen sondern ist physisch offen. Wenn ich z.B. bei einem Feuermelderalarm über ein Script die Tür aufschließen will darf die Tür nicht aufspringen sondern nur aufschließen (Einbrechereinladung bei Abwesenheit). Diese Werte und vieles Mehr wird ja im Adapter angezeigt. Ich wäre auch über Tips dankbar.
Im Material scheinbar gar nicht mehr geht, muss ich jetzt erstmal schauen wie ich alles in IQontrol angezeigt bekomme. In Material hatte ich z.B. alle Batteriebetriebenen Geräte (BWM, Türsensoren, Rauchmelder, Taster usw. auf einer Seite und habe neben den Zuständen immer einen Überblick über die Batteriestände gehabt. Das ist hier nur in der Detailansicht der einzelnen Geräte möglich. Bin gerade an einem Script dran, das alle *.battery Geräte in eine Werteliste mit Namen und Prozentzahl schreibt um alles übersichtlich anzuzeigen. Ist eben alles sehr viel "zusammenkopieren von vorhandenem für einen Unbedarften der nur mit Blockly gut klar kommt.
Ich werde mich melden wenn ich weiter bin.
Für den IQontrol-adapter hätte ich auch einige Ideen und Fragen die ich in Nächster Zeit loswerden will.
Auf jeden Fall ein ganz großes Komliment für die Arbeit, die ihr hier reinsteckt.

Gruß DocGame

[zsb2002]

@s-bormann said in [Neuer Adapter] Visualisierung iQontrol:

Hi, bitte aktualisiere auf die neueste Version, ich vermute, Du hast eine alte Version. Aktuell ist die 0.2.1 (zur Not über das Katzen-Symbol von Gibhub installieren).
Geht es damit?
VG

Läuft....Danke!

[blackeagle998]

@s-bormann
Ich habe über iobroker.pro immer wieder Performance Probleme, wenn ich mehrere Objekte kopiere / editiere.
Zeitweise dauert es sehr lange, bis sich Fenster öffnen bzw. schließen.

Deswegen folgende Fragen:

1. Kann man das Verschieben von Geräten innerhalb einer Ansicht vereinfachen, indem man die Zielposition direkt angeben kann (bspw. per fortlaufender Nummer)?
   --> ggf. kann man das sogar über die aktuelle Ansicht hinaus realisieren?

2. kann man das Kopieren der Geräte innerhalb einer Ansicht vereinfachen, indem man dafür direkt einen Button hinter den Einträgen hat? Optimal wäre, wenn man dazu auch die Zielposition direkt festlegen könnte siehe Punkt 1.
   --> ggf. wäre es auch denkbar, einen Eintrag gleich X-mal kopieren zu können und ab Zielposition einzufügen?

[Negalein]

@blackeagle998 sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann
Ich habe über iobroker.pro immer wieder Performance Probleme, wenn ich mehrere Objekte kopiere / editiere.
Zeitweise dauert es sehr lange, bis sich Fenster öffnen bzw. schließen.

Ist leider auch mit normalem Zugriff so.
4-5 Dinge editieren geht noch. Dann wirds immer langsamer.
Hängt aber anscheinend generell mit ioBroker zusammen.

[mucki]

Hallo,

nur für wen es interessiert...

So sieht iQontrol auf einem Kühlschrank aus

[Beowolf]

Was passiert den beim "Todesstern" anwählen?

[mucki]

@Beowolf
Dann kommt Lord Helmchen und legt alles in Schutt und Asche...

Nee - ist nur eine dieser Bastellampen

[s.bormann]

@Beowolf sagte in [Neuer Adapter] Visualisierung iQontrol:

Was passiert den beim "Todesstern" anwählen?

Das war auch mein erster Gedanke