Die Bilder heißen alle “Preview” und übernehmen nicht den Namen der HA Entity.
Die Vorschaubilder scheinen sich nur zu aktualisieren, wenn in HA eine Aktualisierung stattfindet, z.B. durch das Anzeigen des Vorschaubildes in HA. Ist es eventuell eine Option, ein Refresh-Interval in IPS konfigurierbar zu machen?
Was die Streams angeht, befürchte ich, dass IPS es vno Haus aus nicht kann, denn eine Header-Auth mit Bearer Token ist dort ja nicht vorgesehen. Wir könnten nun bei Symcon ein Feature Request dazu stellen oder in HA das Problem über zusätzliche Erweiterungen lösen. Eine Umsetzung in IPS wäre sicherlich die schönere Variante, da sie universeller ist. Was meinst du?
zu 1: da fehlt leider der entscheidende Rest der Fehlermeldung Kommst du da noch dran? Ich habe auf verdacht nun die Stelle etwas robuster gemacht. Ist aber wohl nur ein Schönheitsfehler beim Update.
zu 2: das ist aktuell so vorgesehen. Die Bild-Variablen sind als technische Preview-Felder umgesetzt und heißen deshalb einheitlich „Preview“ statt den Namen der HA-Entity zu übernehmen. Sie sind ja unterhalb des Gerätes positioniert und damit eigentlich eindeutig. Oder hättest du mal ein Beispiel zum besseren Verständnis?
zu 3: bei mir aktualisieren sie sich regelmäßig alle paar Minuten durch HA. Wie man den Refresh anstoßen kann habe ich noch nicht herausgefunden- Hast du da eine Idee?
Zum Stream: Das sehe ich ähnlich. Langfristig wäre ein Feature in IP-Symcon für Header-Authentifizierung, insbesondere Bearer-Token, die beste Lösung. Das wäre nicht nur für Home Assistant nützlich, sondern generell für viele moderne HTTP-/Stream-Quellen.
Bearer-Token im Header ist heute wohl ein sehr übliches Standardverfahren. Wenn IPS das nativ könnte, wäre das nicht nur für HA-Streams nützlich, sondern allgemein für viele geschützte HTTP-Ressourcen. @paresy : wie siehst du das?
Vielleicht kannst du in deinem Fall im Stream Objekt händisch die Quelle eintragen? Bei meiner Kamera geht das.
Anderes Beispiel: Hier sind drei Bilder in der Instanz. Da alle nur “Preview” heißen, lässt sich nicht ableiten, was dort enthalten ist. Bei HA heißen die drei “Camera”, “Cover image” und “Pick image”.
Ich werde mal beobachten, wie sich die Bilder aktualisieren und mich dazu nochmal melden.
Das Stream Objekt händisch nachtragen hilft bei mir leider nicht, da ja trotzdem der Token fehlt. Die Kamera direkt abfragen geht auch nicht, da die ebenfalls authentifiziert werden muss und das kann nur der HA (Bambu Lab ist da etwas zickig, angeblich “aus Gründen der Sicherheit”, die ja gerne von Herstellern vorgeschoben werden). Die Kamera (Stream) wäre zwar toll, ist aber für mich im Moment noch nicht ganz so wichtig wie die Bilder. Mal schauen, was paresy sagt.
Hast du das Problem noch ab und zu? Ich habe gesehen, dass die Integration der event Entity noch nicht ganz sauber war. Daher gibt es mit dem nächsten Stand dort noch eine leider nicht kompatible Korrektur. Jede event Entität bekommt dann einen „Status“ mit dem Zeitstempel des letzten Ereignisses, sowie separat den Ereignistyp.
In diesem Update ging es vor allem darum, das Mapping der unterstützten HA-Entitäten noch einmal sauber gegen die Doku zu prüfen und an vielen Stellen nachzuschärfen. Dabei sind einige kleinere Inkonsistenzen bei Featurebits, Schreibbarkeit, Zusatzvariablen und der Namensbildung aufgefallen, die ich bereinigt habe.
Betroffen waren unter anderem: cover, climate, light, lock, vacuum, lawn_mower, media_player, fan, humidifier, sensor, binary_sensor, select, number, button, camera, image und event.
Außerdem habe ich die README überarbeitet und auf den aktuellen Stand gebracht.
Version
1.2
Build 50
Wenn euch bei bestimmten Integrationen noch etwas auffällt, gerne melden.
Ich habe es nun hoffentlich korrigiert. In dem Stand sind auch eine Menge weiterer Aufräumarbeiten enthalten. Ich hoffe, ich habe nichts kaputt gemacht.
Die Namen der Bilder haben sich bei mir nicht verändert, sie sind noch immer nur “Image” genau so wie in meinem letzten Screenshot. Um auszuschließen, dass es sich um einen Fehler beim Update handelt, habe ich noch einmal die Instanzen entfernt und über den Konfigurator neu hinzugefügt, was aber nicht half.
Ich habe auch mal versucht etwas tiefer rein zu schauen und ein Debug-Log für das Home Assistant Modul erzeugt. Darin kommt auch der “friendly_name” vor, allerdings nicht im Klartext (“…” gekürzt):
Ich vermute, dass du den Namen erst per API erfragen muss, da er im MQTT stream nicht mitgesendet zu werden scheint. Aus dem Topic ist er für einen Menschen erkennbar, für eine Maschine allerdings wohl eher nicht.
Geräte lassen sich teilweise im HA-Konfigurator anlegen
Lesen und Schreiben zwischen Symcon und HA funktioniert grundsätzlich bei einigen Entitäten
Mein eigentliches Problem
Im MQTT Server in Symcon sehe ich deutlich mehr HA-Daten / Topics als später im HA Splitter bzw. HA-Konfigurator ankommen.
Zeitweise hatte ich deutlich mehr Einträge im Konfigurator, aktuell sind es nur noch rund 45, obwohl im MQTT Server selbst weiterhin deutlich mehr HA-Themen sichtbar sind.
Auffälligkeiten aus dem Debug / Dump
Im früheren Dump hatte ich unter anderem:
Gleichzeitig wurden aber auch Entitäten geladen, also nicht kompletter Ausfall.
Im aktuellen Rohdump sehe ich:
MQTT-Daten kommen sauber an, z. B. unter homeassistant/vacuum/wolf_brs_robo03/...
REST-Requests auf /api/template liefern HttpCode=200
Es werden Entity-Listen zurückgegeben
Zusätzlich wichtig
Auf demselben MQTT Server läuft nicht nur HA, sondern auch anderer MQTT-Traffic, z. B.:
Tasmota
Shelly
Zigbee2MQTT
Solar-Themen
Der HA-Splitter sollte ja eigentlich nur die HA-relevanten Topics verarbeiten, aber ich wollte es erwähnen.
Was ich bereits versucht habe
HA Token neu erstellt
Splitter neu angelegt
Discovery / Konfigurator neu aufgebaut
HA und Symcon mehrfach neu geprüft
Meine Fragen
Ist der Betrieb über den Symcon MQTT Server in diesem Modul vollständig okay, oder ist für stabile Ergebnisse ein separater MQTT Client / externer Broker die bessere Wahl?
Hab ich etwas übersehen oder warum bekomme Ich nur so wenig Entiäten rein?
Falls hilfreich, kann ich die relevanten Debug-Auszüge auch noch gezielt posten.
der Betrieb über den Symcon MQTT Server ist okay. Daran allein sollte es nicht liegen.
Wichtig ist: Die vielen sichtbaren MQTT-Topics sind nicht mit der Zahl der Entitäten im Konfigurator vergleichbar. mqtt_statestream veröffentlicht pro Entität sehr viele Topics, daher ist das normal.
Der auffällige Punkt sind für mich eher diese Meldungen:
• Non-JSON response: Syntax error
• loadEntitiesByIds | API-Fehler (Entities) | {„Count“:50}
Der Konfigurator holt seine Entitäten per REST über /api/template, nicht aus den MQTT-Topics. Dabei werden 50er-Blöcke geladen. Wenn ein Block keine gültige JSON-Antwort liefert, fällt dieser komplett raus. Das könnte erklären, warum nur ein Teil der Entitäten erscheint.
Ich würde daher so vorgehen:
Domain-Filter im Konfigurator aktivieren und testweise nur einzelne Domains laden.
Prüfen, bei welcher Domain der Fehler auftaucht.
Im Splitter Expert-Debug aktivieren und die REST | Response …-Zeilen bzw. LastRestResponse posten oder per PN schicken.
Meine Vermutung: MQTT läuft, aber ein REST-/Template-Block aus HA liefert keine sauber parsebare Antwort und dadurch fehlen ganze Entitätsblöcke im Konfigurator.
Ich habe den Schalter auf „Domänen explizit filtern“ umgestellt. Damit kommen direkt neue bzw. weitere Entitäten dazu.
An welcher konkreten Entität es am Ende liegt, kann ich damit noch nicht sauber sagen. Es muss aber offenbar etwas sein, das außerhalb des aktuell gesetzten Filters liegt. Ich werde das weiter eingrenzen und noch etwas analysieren.
Seit dem Umstellen ist die Meldung mit den 50er-Blöcken jedenfalls verschwunden.
Was mir zusätzlich aufgefallen ist:
Wenn ich in Symcon eine Änderung an einer String-/Select-Entität mache, kommt im Splitter-Log folgender Fehler:
In dem Fall wird auch in Home Assistant nichts geändert.
Wenn ich dagegen zum Beispiel ein Boolean in Symcon ändere, sehe ich im Log, dass ein REST-Command gesendet wird. Das scheint also grundsätzlich zu funktionieren.
Aktuell sieht es für mich so aus, als ob insbesondere select-Entitäten beim Schreiben Probleme machen.
Viele Grüße Torsten
EDIT:
Was mir jetzt auch aufgefallen ist.
Das Steuerungselement für den Roboter selbst ist nicht im Symcon angekommen.
Kann das ggf. aufgrund einer Fehlenden Entität liegen?
Entschuldige bitte, das ich aktuell nichts beitrage, ich komme einfach nicht dazu.
Immer wenn jemand Pläne macht fällt das Schicksal lachend vom Stuhl …
Bezugnehmend auf diesen Thread an anderer Stelle:
Sollte ich das Update vom Mosquitto Broker erst einmal aussitzen?
Da besteht kein Anlass. Ich bin nur daran gescheitert, dass ich keine Bridge vom Mosquitto Server zum Symcon Server einrichten konnte. Das hat aber mit dem Modul nicht direkt etwas zu tun.
Ob es mit einer älteren Mosquitto Version gehen würde, habe ich nicht getestet.
Eine Frage habe ich schon einige Zeit: Über den HomeAssistant Konfigurator werden mir alle “neuen” möglichen Instanzen angezeigt. Das ist sehr praktisch. Allerdings tauchen dort auch immer wieder welche auf, die ich gar nicht haben will. Wenn ich die dann “als gelesen markiere”, verschwinden sie - soweit so gut. Nun ist es aber so, dass die immer wieder neu auftauchen und ich so ständig “neue” Geräte angezeigt bekommen, die gar keine sind. Meine Vermutung ist, dass die MQTT Messages irgendwann rausaltern, die Geräte dann nicht mehr erkann werden und wenn später dann eine neue MQTT Nachricht von HA kommt, dann ist das Gerät plötzlich wieder als neu erkannt.
Gibt es eine Möglichkeitn, die automatische Erkennung von neuen Geräten für den Konfigurator abzuschalten, so dass der nur anfängt zu suchen, wenn ich ihn manuell anschalte?
Folgendes ist mir dabei noch aufgefallen:
