Blink-Kameras MQTT-Bridge

[rabehd]

Abzweig von hier https://forum.fhem.de/index.php?msg=1363714

https://github.com/weirdtangent/blink2mqtt (beruht auf blinkpy).

Ich habe das ausprobiert. Übernahme in meinen Docker-FHEM-Stack als eigener Container.
Läuft als Container ohne Probleme, Konfiguration angepasst (MQTT-Adresse von FHEM), Verifizierungscode als key.txt angelegt und ins Verzeichnis kopiert.

Wie jetzt weiter?

Es werden mir mindestens mit jedem Start von FHEM eine neues Device "blink2mqtt_abc5566" angelegt (blink2mqtt_).

Zusätzlich ist der FHEM-Container in seiner Oberfläche sehr langsam.
Das ist auch noch so, nach dem ich den blink2mqtt-Container gestoppt habe.

Was muss ich tun, um nicht ständig ein neues Device zu erhalten?

[Beta-User]

Vergib eine ClientID oder lösche die CID-Präfixe aus der readingList.

[rabehd]

Vergib eine ClientID oder lösche die CID-Präfixe aus der readingList.

Wo, in FHEM?
Hier?
https://github.com/weirdtangent/blink2mqtt/blob/main/ENVIRONMENT_VARIABLES.md

[TomLee]

Im MQTT2_DEVICE in den readingList-Einträgen den Wert vorne (CID), mit Doppelpunkt entfernen.

readingList <regexp> [readingName|perl-Expression] ...
If the regexp matches topic:message or cid:topic:message either...

[Beta-User]

Hier?

Da scheint es das - warum auch immer - nicht zu geben, aber da würde es m.E. hingehören.

Siehe auch https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#St%C3%A4ndig_neue_Devices?

Vielleicht einen PR im Projekt aufmachen, damit das Setzen einer ClientID dort ergänzt wird.

PS: Ich mache immer beides, also sowohl die ClientID vergeben (das ging bisher immer!), wie auch die CID-Präfixe löschen.

[rabehd]

Das Löschen der CID-Präfixe hilft nicht, er legt weiter lustig neue Device an.

Vielleicht einen PR im Projekt aufmachen, damit das Setzen einer ClientID dort ergänzt wird.

Da bin ich noch am suchen, muss ich dafür einen Account bei GitLab haben?

Solange blink2mqtt aktiv ist, ist FHEM gut ausgelastet/langsam.
Ich habe mich darüber mal mit der KI unterhalten. Die Meinung nehme ich aber nicht einfach so als Maßstab. Deren Aussage war, der MQTT2-Broker von FHEM ist mit TASMOTA, zigbee2mqtt, blink2mqtt... überfordert und es wird Mosquito empfohlen. Sollte ich das glauben?   

[rudolfkoenig]

Das Löschen der CID-Präfixe hilft nicht, er legt weiter lustig neue Device an.

Das hilft schon, die neuen Devices werden fuer unbekannte Topics angelegt.

[JWRu]

Das Löschen der CID-Präfixe hilft nicht, er legt weiter lustig neue Device an.

Ich habe das gleiche Problem. Die Devices unterscheiden sich in den Readings nicht voneinander.

Weiterhin wird bei mir anscheinend immer mal wieder eine neue PIN angefragt, die ich dann per SMS erhalte.

[rudolfkoenig]

Deren Aussage war, der MQTT2-Broker von FHEM ist mit TASMOTA, zigbee2mqtt, blink2mqtt... überfordert und es wird Mosquito empfohlen. Sollte ich das glauben? 

Die Begründung ist falsch, der Vorschlag kann (begrenzt) helfen: da FHEM bei mosquitto die ClientID nicht kennt, wird alles Unbekannte(!) was ueber mosquitto kommt in einem MQTT2_DEVICE gesammelt.

Das kann man zwar mit einem bridgeRegexp Attribut oder vorher angelegten MQTT2_DEVICE-Instanzen mit passenden readingsList Attribut wieder aufteilen, aber das funktioniert bei MQTT2_SERVER genauso.

Man kann die "echten" ClientIDs mit dem MQTT2_SERVER Attribut clientId ueberschreiben, damit wird ein MQTT2_SERVER genaus "dumm", wie ein MQTT2_CLIENT mit mosquitto.
Vor dem  Setzen bitte Doku lesen: https://fhem.de/commandref_modular.html#MQTT2_SERVER-attr-clientId

[rabehd]

Weiterhin wird bei mir anscheinend immer mal wieder eine neue PIN angefragt, die ich dann per SMS erhalte.

Das ist bei mir nicht der Fall. Das war nur einmalig.

[rabehd]

Die Begründung ist falsch,

Dir glaube ich auch eher als der KI

[rabehd]

Das hilft schon, die neuen Devices werden fuer unbekannte Topics angelegt.

Ich muss also einen Weg finden, dem Entwickler von blink2mqtt folgende Wünsche zum Einzubauen zu übermitteln:
 - festes Topic (bisher sehe ich da nur einen prefix zum eintragen)
 - ClientID

[JWRu]

Man kann die "echten" ClientIDs mit dem MQTT2_SERVER Attribut clientId ueberschreiben, damit wird ein MQTT2_SERVER genaus "dumm", wie ein MQTT2_CLIENT mit mosquitto.

Die Folgen für einen schon existierenden Zoo an MQTT2DEVICEs sind natürlich erheblich.
Wäre denn ein Workaround eine zweite MQTT2SERVER Instanz mit einem anderen Port nur für die Devices, die jedesmal eine andere ID nutzen?

[rabehd]

Wäre denn ein Workaround eine zweite MQTT2SERVER Instanz mit einem anderen Port nur für die Devices, die jedesmal eine andere ID nutzen?

Das scheint die Lösung zu sein. Sofort ist die CPU-Last ganz unten.

Das würde zu einer Vermutung der KI passen. Die Nachrichten gehen zwischen FHEM, zigbee2mqtt und blink2mqtt hin und her.
Ist da ein Konfigurationsfehler in meinen FHEM-MQTT2-Broker?

[Beta-User]

Vielleicht würde ein "Copy for forum" für "Unbeteiligte" etwas mehr Licht in die Sache bringen...

Die ClientID würde jedenfalls für unbekannte topics helfen, und "subscriptions" ggf. auch für andere beteiligte Clients erhellen, was die tatsächlich mitlesen.