Vor der Firmware 4.0.0 habe ich selber Mqtt eingerichtet und mir die Information über neue Firmware abgegriffen. Das hat sehr gut funktioniert, ich bekam immer eine Meldung wenn neue Firmware vorhanden war.
Mit dem neuestem Update kam ja die Funktion Auto-Discovery hinzu, und ich habe das auslesen der Variable für das Update aus meiner Homeassitant instanz enfernt und mir die zwei Kameras automatisch einfügen lassen.
Das hat auch soweit gut funktioniert. Jedoch bekomme ich an einer Kamera immer die Meldung das ein Software Update vorhanden ist. Dem ist es aber nicht so.
Auch im Mqtt Explorer sehe ich das die Variable immer auf TRUE ist obwohl es kein Update gibt.
Kamera wurde schon neu gestartet, jedoch ohne erfolg.
Das interesante dabei ist, wenn ich die API im Browser anwende, steht die Variable auf FALSE.
Und das verhalten ist nur bei einer der beiden Kameras.
Läuft der MQTT Broker auf der IP 192.168.178.37 auf einer Kamera? Oder ist das ein externer Broker?
Wir hatten es schonmal das im Mosquitto Broker - extern oder auf der Kamera - die gespeicherten MQTT Daten (retained Topics) Probleme machten. Man bekommt einfach über die Befehl-Topics keine Updates mehr durch.
Bei einem externen Broker kann man dann einmal die Datenbank Datei löschen (der Speicherpfad ist in der Mosquitto Broker Konfigurationsdatei angegeben) und den Broker neustarten.
Bei der Kamera hat ein Soft-Reset (über die WebUI bei Beibehaltung der Netzwerk und Benutzer-Konfiguration) den gleichen Effekt.
Danach werden alle Einträge nochmal neu erstellt und bislang liess sich das Problem dadurch immer beheben.
Allerdings sind in dem Fall alle Topics betroffen. Also durch Klicken in der WebUI lassen sich die Status-Topics aktualisieren. Durch ein Befehl-Topic Update jedoch nicht.
Wenn nur das eine Status-Topic updateavailable betroffen ist, würde ich einmal nachsehen ob man dieses eventuell irgendwo eingebunden hat. Also einen MQTT Klienten hat, der das Satus-Topic aktualisiert anstelle des Befehl-Topics. man kann z.B. einmal über den MQTT Explorer den Status auf 0 stellen und schauen ob dann von irgendwo wieder die 1 herkommt.
Ich habe insgesamt vier Kameras auf v4.0.1 geupdatet. Davon zeigt nur die 9820 „updateavailable = 0“, die drei anderen (9808, 8401, 9408) stehen alle auf „1“. Über CGI abgefragt steht überall „0“, ganz wie Du beschreibst.
Dann habe ich in der MQTT-Datenbank nachgesehen: Das Topic „system/update/updateavailable“ war gültig, aber markiert als „retained“. Daraufhin habe ich es in der DB gelöscht und die Kamera neu gestartet. Und siehe da: Der Wert wurde gar nicht neu übertragen. Der Stand war offenbar noch der alte, vor dem Update v4.0.0 → v4.0.1.
Dafür gibt es nun aber das neue Topic „available“. Wurde das vielleicht einfach umbenannt von zuvor „updateavailable“?
Tatsächlich steht auch der „latest“ Topic nicht auf einer gültigen Version:
Dabei wurde dieser im Gegensatz zu „updateavailable“ durchaus neu übertragen.
Kann es sein, daß die Kamera mit v4.0.1 den ganzen Update-Check mit dem zugehörigen Reporting nicht richtig ausführt und deswegen alte Werte stehenbleiben bzw. nicht erneuert werden? Im UI scheint alles ok, dort steht alles auf grün/„ist aktuell“.
Das sieht man, wenn der Update Check in der Kamera fehl schlägt. In der WebUI unter Sytem/Update bekommt man dann einfach die installierte Version angezeigt und hinter der Versionsnummer keine Revisionsnummer.
Der CGI Befehl param.cgi?cmd=getupdateavailable fragt nicht direkt beim Update Server an, sondern nur bei der Kamera. Also nur nachdem die Kamera einmal erfolgreich online nachgefragt hatte, sieht man dann auch beim Topic system/update/available den neuen Wert - spätestens nach 3600s (das Update Intervall für dieses Topic).
Danke für den Hinweis - das ist die Lösung des Problems! @Duescha Für das neue Autodiscovery wird das Topic system/update/available verwendet - nicht mehr system/update/updateavailable.
Letzteres war retained - wird also vom Broker beibehalten, auch wenn die Kamera es nicht mehr nutzt. D.h. wenn man es über den MQTT Explorer löscht wird es nicht mehr wiederkommen.
Das neue system/update/available ist nicht retained - wird also erst dann angezeigt werden, wenn es ein Update des Topics gab (also wenn eine neue Firmware Version bereitsteht).
Also genau die im Thread beschriebenen Fehler … btw: die CAMs werden nachts neu gestartet …
In der 3.x Version war das bisher kein Problem (auch nicht mit externem Mosquitto Broker !) - besonders der Topic system/update/updateavailablehat zuverlässig mit Retain Flag funktioniert! Jetzt mit system/update/available und ohne Retain Flag ist die ganze Update-Info nicht mehr eindeutig / konsistent z.B.: bei HA Neustart und fehlendem ‘avaible‘ Eintrag steht dort ‘unbekannt‘. Warum wird der ‘avaible‘ Eintrag nicht auch auf ‘retained‘ gesetzt?
Die (0) kommt nicht vom MQTT Dienst, sondern vom internen Update Check - immer dann, wenn die Kamera,erfolglos, versucht den Update Server zu kontaktieren. Wir schauen gerade wie man das fürs MQTT Topic umgehen kann.
Kann das eine Art race condition nach einem Reboot sein? Daß der Updater nach dem Start „zu früh“ läuft, wenn noch keine Netzwerkverbindung besteht, dann aber erst ein paar Tage später einen zweiten Versuch startet?
Bei mir hat sich die Lage von selbst bereinigt, auch unter „latest“ steht bei mir inzwischen überall die aktuelle Version. Allerdings hat das ein paar Tage (gerechnet seit dem letzten Reboot) gedauert.
Also bei mir starten die Kameras einmal in der Woche neu. Sonntag um 00:00 Uhr.
Das habe ich natürlich nicht bedacht als ich das als Antwort markiert habe. (War nur glücklich das es funktioniert hat.)
Jetzt sehe ich bei mir auch das selbe Bild wie bei dir.
Es wird ein Update angezeigt obwohl es keines gibt.
Somit ist die Anpassung nur temporär bis zum nächsten neustart der Kamera.
Mit dem nächsten Release wird anstelle der 0 - als Indikator eines fehlgeschlagenen Versuchs den Update Server zu kontaktieren - die bereits installierte Version als Default-Wert angezeigt werden. Damit wird diese falsche Update Benachrichtigung unterdrückt werden.
