HomeConnectLocal – Home-Connect-Geräte lokal und ohne Cloud in FHEM steuern

[Shadow3561]

Moin,

danke fürs erneute Testen und die ausführliche Rückmeldung.

Ich habe v1.61 und v1.62 nochmals direkt verglichen. Die eigentliche Kommunikation und die dynamische SetMap sind unverändert. Lediglich FridgeFreezer wurde als Gerätetyp ergänzt und die Reading-Benennung für Kühl- und Gefrierfach angepasst.

Dass auch die Tür-Readings nicht mehr aktualisiert werden kann ich nicht verstehen. Vielleicht lädst du noch einmal die vorige Version und schaust ob es wieder funktioniert.

Zum Proxy-Port: Der Hash sorgt dafür, dass bei FQDN und IPv6 ein reproduzierbarer lokaler socat-Port entsteht, ohne dass man ihn manuell konfigurieren muss. Bei IPv4 verwenden ich weiterhin 10000 + letztes IP-Oktett. Der Hash-Port hat also nichts mit dem eigentlichen WebSocket-Port des Kühlschranks zu tun.

Die JsonMod-Warnung deutet auf einen Fehler im Zahlenparser von JsonMod hin. Die zweite Warnung (to_json Prototype mismatch) sieht nach einem Konflikt zwischen Perl-Modulen beziehungsweise deren Imports aus. Beides untersuche ich getrennt, kann mir den Fehler aber im Moment nicht erklären da ich nichts betreffendes im Modul geändert habe.
Hast du das Device, wie ich es vorgeschlagen habe, komplett gelöscht und neu angelegt? Wenigstens die alten readings solltest du mit

Code Auswählen Erweitern

deletereading Device .* löschen.

Könntest du mir bitte noch die Internals MappingLoaded, MappingPrefix, MappingError (falls vorhanden) und LastSetList schicken?

Interessant wäre außerdem, ob die XML-Dateien beim Start korrekt geladen werden und wie viele Features beziehungsweise Einstellungen das Modul dabei erkennt.

Dann kann ich  versuchen gezielt herauszufinden, weshalb die SET-Befehle fehlen, ohne an der funktionierenden Kommunikation unnötig etwas zu ändern.

Gruß
Daniel

[JudgeDredd]

So, habe das (neue) Modul aus Post#23 nochmal auf meiner Integrationsumgebung ausprobiert.

Vorgehensweise:

• (altes) Device gelöscht
• Modul (aus Post#23) sowie die anderen Dateien kopiert
• shutdown Restart
• Device erstellt (mit FQDN)
• set <device> connect
• set <device> reloadMapping

Danach werden weder die Tür-Readings (beim öffnen/schließen) aktualisiert, noch erscheinen irgendwelche neuen SET/GET Befehle.
(ich gehe nicht davon aus, das es Probleme bereitet, wenn auf der Prod-Umgebung zeitgleich das Device (mit dem "alten" Modul) läuft)

Der Socat-Port ist auf 39559 (>20000 %40000). Demnach scheint zumindest die FQDN Logik zu funktionieren.

EDIT: Die Temperatur-Readings unterscheiden nun korrekt zwischen Freezer_SetpointTemperature/Refrigerator_SetpointTemperature.

[JudgeDredd]

Ich bin gerade nochmal auf die Ursache nach den fehlenden Reading-Updates gegangen.

Dabei ist mir folgendes aufgefallen

Im Modul (aus Post#23) prüfst Du in Zeile 5286 auf:

Code Auswählen Erweitern

    if (($d->{action} // '') eq 'NOTIFY'
        && ($d->{resource} // '') eq '/ro/descriptionChange')und springst danach mit RETURN wieder aus der SUB.
Das ist der JSON bei Tür-Zu:

Code Auswählen Erweitern

{"sID":261728228,"msgID":1220581850,"resource":"/ro/descriptionChange","version":1,"action":"NOTIFY","data":[{"uid":4097,"parentUID":0,"value":0}]}Dadurch wird das Mapping ab Zeile 5326 nicht mehr ausgeführt.

Wenn ich das RETURN in Zeile 5291 auskommentiere, dann kommen die Reading-Updates wieder.
Habe aber nicht weiter geschaut, ob sich dadurch andere (spätere) Probleme ergeben.