@nobl : Ich habe eine Senec-Wallbox und unterstütze dich gerne. Was genau brauchst du?

@garfonso : So, jetzt bin ich endlich mal zum Testen des input_datetime gekommen. Grundsätzlich funktioniert die Entity, außer, dass ich einen "input_datetime" mit nur einem Zeitwert (also "has_date": false, "has_time": true) nicht so hinbekomme, wie ich das erwarte. Die Entity mit nur einem Zeitwert hat bei den Einstellungen ebenfalls ein Datum.

So sehen die drei input_datetime in einer Entity Card aus:

Und hier die drei Entities aus iobroker:

Nur Datum

{
  "_id": "0_userdata.0.date",
  "type": "state",
  "common": {
    "name": "date",
    "role": "date",
    "type": "number",
    "read": true,
    "write": true,
    "desc": "Datum",
    "custom": {
      "lovelace.0": {
        "enabled": true,
        "entity": "input_datetime",
        "name": "Datum",
        "has_date": true,
        "has_time": false
      }
    }
  },
  "native": {},
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1618051146774,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Nur Zeit

{
  "_id": "0_userdata.0.time",
  "type": "state",
  "common": {
    "name": "time",
    "role": "date",
    "type": "number",
    "read": true,
    "write": true,
    "desc": "Uhrzeit",
    "custom": {
      "lovelace.0": {
        "enabled": true,
        "entity": "input_datetime",
        "name": "Zeit",
        "has_time": true,
        "has_date": false
      }
    }
  },
  "native": {},
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1617949846826,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Datum und Zeit

{
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1618050479040,
  "common": {
    "name": "datetime",
    "role": "date",
    "type": "number",
    "desc": "Datum und Zeit",
    "read": true,
    "write": true,
    "custom": {
      "lovelace.0": {
        "enabled": true,
        "entity": "input_datetime",
        "name": "DatumZeit",
        "has_time": true,
        "has_date": true
      }
    }
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "0_userdata.0.datetime",
  "type": "state"
}

Ich habe gerade festgestellt, dass zusätzlich zu den Climate-Entitäten noch eine Sensor-Entität mit der aktuellen Temperatur automatisch angelegt wird. Das finde ich super!

@garfonso: Die JSONs sind unterwegs.

So flach sind meine Hierarchien eigentlich nicht, ich habe Raum (channel) - Geräteart (channel; nur, wenn mehrere Geräte einer Art im Raum sind) - Gerät (channel) - States, also in der Regel eine dreistufige Hierarchie.

Aber du hast natürlich Recht, bei Homematic ist dieses Up-and-Over (in den Parent und von dort in die anderen Channels) notwendig, bei mir in aller Regel nicht. Ich nutze mittlerweile konsequent für alle Geräte, die ich steuern will, LinkedDevices, daher greift der Type Detector nirgends auf die Ursprungsdevices zu.

@garfonso Hab jetzt mal alle Custom Cards aktualisiert (und ausgemistet ;)). Bisher ist der Glitch nicht wieder aufgetreten.

@garfonso : Hi Garfonso! Ja, das sind manuell erstellte Sensoren für States, in die ich per JavaScript eine EPOCH-Zahl schreibe als Timestamp bzw. Wert für ein zukünftiges Datum. Ich habe die Sensoren entsprechend auf "Timestamp" eingestellt, funktioniert sehr gut! Vielen Dank!

Hallo zusammen!

Ich bekomme die Services input_number.decrement und input_number.increment nicht wie in der Doku beschrieben ans Laufen, sondern erhalte die folgende Fehlermeldung.

Hat irgendwer eine Idee, woran das liegt?

Unknown service: increment ({"type":"call_service","domain":"input_number","service":"increment","service_data":{"step":5},"id":363}) 

Hier der Auszug aus der YAML:

    tap_action:
      action: call-service
      service: input_number.increment
      service_data:
        entity_id: input_number.Haus_Energie_Wallbox_evChargeLimitSOCSet
        step: 5

input_number.set_value funktioniert hingegen problemlos mit folgender YAML:

    tap_action:
      action: call-service
      service: input_number.set_value
      service_data:
        entity_id: input_number.Haus_Energie_Wallbox_evChargeLimitSOCSet
        value: 50

Ich habe leider noch einen Fehler gefunden, diesmal auch ohne die Mushroom Cards. Auch hier stürzt Lovelace ab mit Verweis auf rgbGetParsers.

lovelace.0
2024-12-06 20:39:00.913	info	terminating

lovelace.0
2024-12-06 20:39:00.411	warn	Terminated (UNCAUGHT_EXCEPTION): Without reason

lovelace.0
2024-12-06 20:39:00.411	info	terminating

lovelace.0
2024-12-06 20:39:00.410	info	cleaned everything up...

lovelace.0
2024-12-06 20:39:00.402	error	Cannot set properties of null (setting '0')

lovelace.0
2024-12-06 20:39:00.402	error	TypeError: Cannot set properties of null (setting '0') at rgbGetParser (/opt/iobroker/node_modules/iobroker.lovelace/lib/converters/light.js:324:47) at /opt/iobroker/node_modules/iobroker.lovelace/lib/server.js:826:38 at Array.forEach (<anonymous>) at WebServer.onStateChange (/opt/iobroker/node_modules/iobroker.lovelace/lib/server.js:802:22) at Object.stateChange (/opt/iobroker/node_modules/iobroker.lovelace/main.js:54:35) at change (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/cjs/lib/adapter/adapter.js:7312:31) at Immediate.<anonymous> (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/build/esm/lib/states/statesInRedisClient.js:291:37) at process.processImmediate (node:internal/timers:483:21)

lovelace.0
2024-12-06 20:39:00.399	error	unhandled promise rejection: Cannot set properties of null (setting '0')

lovelace.0
2024-12-06 20:39:00.398	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().

@garfonso

Hi Garfonso!

Das kann durchaus sein. Die Lampen können zwischen einem Weiß-Betriebsmodus, der über die Lichttemperatur gesteuert wird, und einem Farb-Betriebsmodus umschalten. Vom Weiß-Modus in den Farbmodus wird die Lichttemperatur auf 0 gesetzt. Anders herum sehe ich allerdings nicht, dass die Farbwerte auf null gesetzt würden (oder auf 0), insofern weiß ich nicht, warum ich immer wieder Crashes hatte.

Ausgestiegen ist er bei der Zeile targetAttributes.rgb_color[index] = val;. Daher sah es für mich so aus, dass rgb_color nicht initialisiert war.

Hi @garfonso,

Entschuldige die späte Antwort, ich war beruflich eingespannt. Ich habe jetzt mal Diverses ausprobiert und es läuft mit dem Standard-Alarm-Panel wieder. Der Fehler scheint bei mir gelegen zu haben. Das Mushroom Card Alarm Panel klappt nicht, aber das kann an einer Versionsinkompatibilität liegen.

Ein anderes nerviges Verhalten habe ich aber leider feststellen müssen. Ich benutze ein paar Seiten in meinem Dashboard für smarte Schalter mit Display (NSPanel Pro). Für diese verstecke ich den Header und habe bei den entsprechenden Browser-Objekten, z.B. "lovelace.0.instances.8e7570cc-fae9c9a6" den "hideHeader" State jeweils auf true gesetzt. Bei allen anderen Browser-Objekten habe ich die entsprechenden States auf false gesetzt, ebenso den Default-Wert "lovelace.0.instances.hideHeader".

Nur leider "vergisst" Lovelace immer wieder, in den Browsern den Header zu zeigen, in denen er das soll. Ich muss teilweise mehrmals Reload drücken, bis die Headerbar angezeigt wird.

Könntest du prüfen, warum dies so ist? Es wäre wirklich toll, wenn die Anzeige des Headers zuverlässig über die States steuerbar wäre.

Viele Grüße!

@nobbiman : Hi Nobbiman!

Der Adapter schreibt die Offset-Werte unmittelbar. Und zumindest bei mir tauchen sie dann auch unmittelbar in Controme auf.

Hier siehst du es mal mein Beispiel: Beim Öffnen eines Fensters wird im Raum ein Offset von -10K gesetzt. Das ganze geht unmittelbar, da sind maximal Sekundenbruchteile an Verzögerung drin.

Wo jetzt genau die Verzögerung bei dir herkommt, weiß ich nicht. Aber liest der webCal-Adapter deinen Google-Kalender nicht nur periodisch aus? Zumindest der iCal-Adapter liest nur alle X Minuten, und das könnte natürlich zu einer erheblichen Verzögerung kommen.

Du schriebst oben (am 14.01.2025), dass die Offset-Änderungen in "Wohnzimmer - Offset - api - Raum" sich gar nicht in Controme wiederspiegeln. Ist das gelöst? Falls du immer noch keine Änderungen in Controme siehst, dann müsstest du bitte mal den Debug-Modus aktivieren, manuell den API-Wert setzen (indem du einfach in den Api-Raum-State einen Wert einträgst) und dann den Log hier posten.

Viele Grüße!

Hi @Garfonso!

Ich nutze jetzt die v5 Alpha 1 schon ein paar Wochen. Sie funktioniert bisher problemlos. Einige Kleinigkeiten haben sich geändert, insbesondere funktioniert manuelle Spaltenumbrüche mit der custom:layout-break-Karte in der Vertical View nicht mehr, aber das liegt an veralteten Custom-Cards und lässt sich auf die neuen Section Views umstellen.

Viele Grüße!

Hi @Garfonso

Ich habe mal die neue v5 alpha installiert. Bei der Vertical Layout Card funktionieren die Layout Break Cards nicht mehr. Die Layout Break Cards steuern eigentlich, wann eine neue Spalte begonnen wird. Aktuell sind die Karten trotz Layout Break alle untereinander. In der 4.1.15 funktionierte das noch.

Viele Grüße!

@nobbiman : Hi nobbiman! Danke für das Feedback, da hatte ich zu kurz gedacht. Auf Github (noch nicht im Latest) findet sich jetzt eine Version, die die Warnungen unterdrücken sollte. Außerdem berücksichtigt sie jetzt unterschiedliche API-Versionen, da bei den älteren APIs bestimmte Werte nicht mitgeliefert werden.

In der Adapter-Konfiguration gibt es die Checkbox "Show log warning for Null value"/"Log-Warnungen für Null-Werte anzeigen". Nur wenn diese Checkbox gesetzt ist, werden die Warnungen oben weiter angezeigt, sonst werden sie unterdrückt.

Prüft das gerne mal!

Ich habe die 0.5.6 fertiggestellt. Oberflächlich hat sich nicht viel geändert, unter der Motorhaube ist der Adapter aber wesentlich robuster geworden und prüft die API-Rückmeldungen viel genauer.

Installiert gerne mal die 0.5.6 und gebt Feedback, ob noch irgendetwas fehlschlägt.

@nobbiman : In der v0.5.4 sollte das Problem mit dem Sensor-Namen nicht mehr auftauchen. Es lag daran, dass ich leider bei einem Teil der Sensor-Aufrufe unsichere Zeichen bereits gefixt habe, aber leider nicht überall.

@digifreak : Hi Digifreak,

probiere bitte mal die v0.5.4. Sollten damit weiter Fehler auftauchen, schick mir bitte mal das Debug-Log (wie per Email schon geschrieben, gerne auch in der Silly-Einstellung).

Viele Grüße!

@nobbiman Die Warnung aus dem Log lautet "State "controme.0.2.sensors.VSensor*1.actualTemperature" has no existing object", in deinem Objektbaum heißt das Device aber "VSensor_1". Das muss ich mir anschauen. Du kannst es deinerseits abstellen, wenn du den Sensor vielleicht in VSensor1 umbenennst, aber letztlich ist es ein Fehler im Adapter. Danke, dass du es bemerkt hast.

Du kannst das Objekt in ioBroker löschen, es wir aber den Fehler nicht abstellen, da dieser vom Adapter generiert wird und darauf hindeutet, dass der Adapter den State nicht findet, den er schreiben will. Eben weil der State anders heißt, als erwartet.

@nobbiman Also ich schreibe immer wieder Werte über das Interface zurück in den API-Raum-State, z.B. um meine Fenstersensoren zu testen. Ich habe es gerade noch mal getestet, die Werte werden verarbeitet. Hier mal, wie es bei mir aussieht:

Wichtig ist, dass der API-Raum-Wert (entsprechend der API-Dokumentation) von Controme nach 5 Minuten wieder zurückgesetzt wird. Du musst, wenn du den Wert aufrechterhalten möchtest, diesen periodisch immer wieder schreiben.

Vielleicht stellst du den Adapter mal auf Debug und postest die Log-Einträge.

Viele Grüße

Marc

Hi @garfonso,

Entschuldige die späte Antwort, ich war beruflich eingespannt. Ich habe jetzt mal Diverses ausprobiert und es läuft mit dem Standard-Alarm-Panel wieder. Der Fehler scheint bei mir gelegen zu haben. Das Mushroom Card Alarm Panel klappt nicht, aber das kann an einer Versionsinkompatibilität liegen.

Ein anderes nerviges Verhalten habe ich aber leider feststellen müssen. Ich benutze ein paar Seiten in meinem Dashboard für smarte Schalter mit Display (NSPanel Pro). Für diese verstecke ich den Header und habe bei den entsprechenden Browser-Objekten, z.B. "lovelace.0.instances.8e7570cc-fae9c9a6" den "hideHeader" State jeweils auf true gesetzt. Bei allen anderen Browser-Objekten habe ich die entsprechenden States auf false gesetzt, ebenso den Default-Wert "lovelace.0.instances.hideHeader".

Nur leider "vergisst" Lovelace immer wieder, in den Browsern den Header zu zeigen, in denen er das soll. Ich muss teilweise mehrmals Reload drücken, bis die Headerbar angezeigt wird.

Könntest du prüfen, warum dies so ist? Es wäre wirklich toll, wenn die Anzeige des Headers zuverlässig über die States steuerbar wäre.

Viele Grüße!