Habe gestern ein Update laufen lassen. Bei mir lief anschließend alles normal. 
Merwürdig. HA ist nun aktuell (2021.9->2022.3).
HACS konnte ich mit Entfernen und Einfügen der Integration wieder zum Laufen bringen (incl. neuer Github-Anmeldung ohne Token).
Wenn ich HACS aktualisieren will, sieht es so aus, als ob der Ordner custom_components/hacs aktualisiert wird. Wird er aber nicht. Die alte Version ist noch vorhanden.
Die neue HACS Version manuell reinkopiert liefert bei Start von HA Fehler wegen fehlender Dateien.
Welche HACS-Version hast du aktuell?
Edit:
Ich glaube, ich habe es nun hinbekommen. Nach etlöichen Versuchen, HACS irgendwie manuell zu aktuualisieren, hat es nur funktioniert durch
- Löschen der Ingeration in den HA-Einstellungen
- Löschen des hacs-Verzeichnisses in custom_components
- HA-Neustart (mehrfach)
- Kopieren der HACS 1.21 Version nach custom_components. Man muss die Lastest 1.21 nehmen, weil sonst das Verzeicnis hacs_frontend fehlt.
- Integration einfügen incl. Authorisierung in Github.
Jetzt kann ich auch die HACS-Komponenten wieder aktualisieren.
Ich hoffe, das ewar es jetzt.
HA ist für mich damit leider immer noch eine Tekki-Bastellösung
System Health
| version | core-2022.3.1 |
|---|---|
| installation_type | Home Assistant OS |
| dev | false |
| hassio | true |
| docker | true |
| user | root |
| virtualenv | false |
| python_version | 3.9.9 |
| os_name | Linux |
| os_version | 5.10.92-v8 |
| arch | aarch64 |
| timezone | Europe/Berlin |
Home Assistant Community Store
| GitHub API | ok |
|---|---|
| GitHub Content | ok |
| GitHub Web | ok |
| GitHub API Calls Remaining | 4806 |
| Installed Version | 1.23.0 |
| Stage | running |
| Available Repositories | 1073 |
| Downloaded Repositories | 32 |
Home Assistant Cloud
| logged_in | false |
|---|---|
| can_reach_cert_server | ok |
| can_reach_cloud_auth | ok |
| can_reach_cloud | ok |
Home Assistant Supervisor
| host_os | Home Assistant OS 7.4 |
|---|---|
| update_channel | stable |
| supervisor_version | supervisor-2022.01.1 |
| docker_version | 20.10.9 |
| disk_total | 439.4 GB |
| disk_used | 10.1 GB |
| healthy | true |
| supported | true |
| board | rpi3-64 |
| supervisor_api | ok |
| version_api | ok |
| installed_addons | File editor (5.3.3), Samba share (9.5.1), Terminal & SSH (9.3.0) |
Lovelace
| dashboards | 4 |
|---|---|
| resources | 19 |
| views | 7 |
| mode | storage |
HACS:
1 Like
Ich vermute, dass es ein Versionaproblem ist. Vermutlich war der Versionssprugn bei HA zu groß und die alte HASC-Version lief damit nicht mehr. Hat man ja leider öfter, dass HA “breaking changes” einbaut.
Bin gerade draufgekommen, dass meine rollershutter 2/3 keinen Status in HA anzeigen. Broadcast usw. bringt auch nichts.
Macht es sinn irgend welche apps mqtt client, broker oder hub auf dem raspberry zu installieren bzw. möglich?
Es macht nur Sinn, den Broker auf einem Server (Raspi, Docker-Container…) zu installieren und als zentrale Instanz zu verwenden.
Client und Hub müssen auf Homey laufen.
Probier mal bitte, die MQTT Hub App neu zu starten. Nach einem HA-Neustart ist das manchmal notwendig, um die Verbindung wiederherzustellen.
Ansonsten die MQTT Hub App neu starten und den Schieberegler auf Running stellen. Der Status in HA sollte sich jetzt aktualisieren.
Die Beta App des Hub funktioniert besser als die Stable.
Dann werde ich das mal versuchen
Das hat das Problem gelöst. Kann man das auch irgendwie automatisieren?
Das wurde auch schon im App-Thread zum MqttHub diskutiert. Eine Lösung gibt es noch nicht. Drr Hub macht beim Start bon HA einen Broadcast. Er reagiert also auf die Birth-Message. Ein reines Senden der Werte bringt diese zwar nach HA, aber der Automatismus zum Zurückliefern der Änderungen in HA geht dann nicht. Ich vermute, der App-Neustart erzeugt die komplette HA-Discovery neu.
Ich habe noch keinen Weg gefunden, das zu automatisieren. Evtl. indem man im Mqtt-Client die Birth-Topic liest und dann per Flow die Hub-App neu startet. Werde ich mal ausprobieren…
1 Like
Ich habe ne schnelle Lösung gebaut…
Da der Broadcast auch zum erneuten Senden der online-Topic führt, kann man leider nicht nur darauf reagieren. Der Einfachheit halber habe ich das mit einer Logik-Variable gemacht. Die wird immer auf den HA-Statsu gesetzt. Bei Änderung wird der 2. Flow gestartet, der dann den MQTT-Hub neu startet:
Logik-Variable: “HA Status”, Typ Text
-
Flow:
Trigger durch die MQTT-Client-App mit der HA-Status-Topic. Der Inhalt der Topic wird als lokaler Tag bereitgestellt. Der wird dann in die Variable übertragen.
-
Flow
Bei Änderung der Variable wird der Onhalt geprüft. Wenn “online”, dann Hub neu starten.
Wie bekomme ich diesen Auslöser?
Im WENN-Bereich wähslt du statt eines Gerätes die Mqtt-Client-App und dann den Trigger “receive topic trigger”
Das ist mir klar aber wie kommst du auf das hass/status?
Ach so…das ist die Birth/Lastwill-Topic, die im Mqtt-Client in Homeassistant gesetzt ist. hass/status ist der Standardwert, solange du ihn in der HA-Integration nicht änderst.
Die Topic wird übrigens auch vom Mqtt-Hub verwendet. Daran erkennt er ebenfalls die Änderung un starten den Boradcast. Zu sehen in den App-Einstellungen des Hub
1 Like
Das ist die Einstellung im Hub. Der lauscht dann auf diese Topic.
Du solltest hier den Wert eintragen, der in HA in der Mqtt-Integration gesetzt ist.
Dazu die Integration in HA aufrufen, “Konfigurieren” klicken, Anmeldedaten bestätigen. Dann siehst du die Optionen.
1 Like
Du kannst auch den MqttExplorer installieren (Windows) und dich am Broker anmelden. So sieht man wenigstens, was im Broker so durchläuft.
Hast du hierzu evtl auch noch eine Anleitung?
Was genau brauchst du?
Ich habe den Broker als Docker-Container auf einem Qnap-Nas laufen. Siehe Post #2 weiter oben.
@Undertaker kann bei Fragen zum Raspi weiterhelfen. Sie dazu auch den ersten Post ganz oben.
Ein neustart von HA hat die Probleme verschwinden lassen danke für deine Hilfe.
