Identifikation über UPNP UND API

[SukramJ]

Zur Identifikation einer RM Instanz hatte ich mir mal überlegt statt einer IP-Adresse andere Identifikationsmerkmale eine RM Instanz zu verwenden.

Über die JsonAPI kann kann über die JsonAPI (CCU.getSerial) eine Seriennummer abfragen.
Diese Seriennummer finder ich auch in der UPNP Nachricht http://{ccu_ip}/upnp/basic_dev.cgiunter modelDescription.

Hört sich erstmal gut an, aber beim Testen kam dann raus das ein HM-MOD-RPI-PCB unter debmatic eine BidCos-style SN (PEQ22XXX) zurückgibt, während in der UPNP-Nachricht nur eine HmIP-style Adresse (3014XXXX) zu finden ist.

Ich nehme mal an das PEQ22XXXXXX dann auch in der Datei /var/ids zu finden ist.

root@odroidc2:~ # pivccu-info
piVCCU version: 3.61.7-68
Kernel modules: Available
Raw UART dev:   Available
HMRF Hardware:  HM-MOD-RPI-PCB
 Connected via: GPIO (/dev/raw-uart)
 Board serial:  PEQ22XXXXXX
 Radio MAC:     0x6BDD88
HMIP Hardware:  HM-MOD-RPI-PCB
 Connected via: GPIO (/dev/raw-uart)
 SGTIN:         3014F711A061A7XXXX
 Radio MAC:     0xBC58AC
State:          RUNNING

Nach aktuellem Stand kann ich nur die IP-Adresse als gemeinsamen Identifikator verwenden.
Gibt es hierzu Alternativen die ich noch nicht bedacht habe.

[jens-maus]

Versteh das Problem noch nicht ganz!? Was du ja versuchst zu bekommen ist eine eineindeutige ID und dafür bietet sich in der Tat die Seriennummer bzw. SGTIN an die du über CCU.getSerial() ja erhalten solltest. Wieso ist es ein Problem wenn dann allerdings debmatic hier eine andere Art der Seriennummer zurückgibt?!?

[SukramJ]

Oder man macht einen Eintrag in der Doku:
"Wenn ihr folgende Kombination nutzt müsst ihr die zusätzliche Integration ignorieren."
Muss ich mal mit @danielperna84 abstimmen

[danielperna84]

Also ich finde so einen Hinweis in der Doku ok. Wenn ich das richtig sehe würde man den Discovery-Hinweis ja auch bekommen wenn man die Integration wegen TLS manuell mit FQDN konfiguriert hat. Wäre dann also auch ein Szenario beim dem man den Usern sagen kann "klick' auf ignorieren". Zumal das ja kein Problem ist, sondern nur für Irritation sorgt.

[SukramJ]

TLS / FQDN sind hier nicht relevant. Ich verwende jetzt in v1.0.5 die letzten 10-Stellen der Seriennummer und die Doku habe ich angepasst.

@jens-maus Wie ist eigentlich der Status beim RaspberryMatic-Addon? Soll da Auto-Discovery schon funktionieren?
Ich hab da schon Fälle gesehen, kann das aber bei mir nicht reproduzieren.

[jens-maus]

@jens-maus Wie ist eigentlich der Status beim RaspberryMatic-Addon? Soll da Auto-Discovery schon funktionieren?
Ich hab da schon Fälle gesehen, kann das aber bei mir nicht reproduzieren.

Prinzipiell sollte das funktionieren, ja. Nur wenn das via Multicast UDP funktioniert gehen momentan ein paar Sachen nicht da Docker prinzipiell kein multicast udp traffic ohne weiteres zulässt. Siehe dazu #1373 und home-assistant/plugin-multicast#17. D.h. ein Home Assistant Addon das Dienste einsetzt die multicast udp nutzen funktionieren momentan nicht korrekt bis home-assistant/plugin-multicast#17 umgesetzt wurde. Und ich hab es gerade nicht voll auf dem Schirm, kann aber gut sein das das auch für das Auto-Discovery gilt das du einsetzt.

[SukramJ]

Danke, ich werde die Tickets dann mal beobachten.