Guten Morgen,
ich bin gestern bald an einem Problem verzweifelt.
Ziel ist es, die Steckdose PCA301 über den CUL(culfw) zu steuern und vorhandene Ressourcen zu nutzen.
Das funktioniert über Dispatch aus dem CUL heraus auch grundsätzlich, sprich, das device wird per autocreate angelegt.
Dann aber bleiben die updates aus. Es gibt keinerlei Logmeldungen. Dadurch fällt auf, dass bei jedem weiteren Datentelegramm vom CUL das 36_PCA301 gar nicht mehr aufgerufen wird. Ich hab dann festgestellt, dass das an der positiven "Doubletten"-Prüfung in der Dispatch-Funktion liegt. Ich gehe jetzt mal davon aus, dass die prinzipiell richtig funktioniert. Sieht man sich die Fingerprintfunktionen an, so fällt auf, dass scheinbar die Fingerprint-Funktion beim Jeelink in dessen logischen Modulen, die des CUL aber im physischen Modul stattfindet. Und das scheint sich jetzt in die Quere zu kommen, wenn ich mit dem CUL ein für den Jeelink entwickeltes logisches Modul nutzen möchte.
Konkrete Ausprägung der Fingerprint-Funktionen:
00_CUL - $msg = substr($msg,

if($msg =~ m/^81/ && length($msg) >

;
IT, FS20 - keine Fingerprintfunktionen
00_Jeelink - leere Fingerprintfunktion
PCA301 - return ( "", $msg )
TRX - Fingerprint weder in physikalischem, noch in logischen Modulen
Signalduino - Fingerprint in physikalischem Modul
Wenn ich in meinem Fall die Funktionalität aus der Fingerprint-Funktion des CUL ODER PCA301 entferne, funktioniert alles wie es soll(abgesehen natürlich von einer korrekten sinnvollen Doubletten-Prüfung.

)
Ich spekuliere daher mal, dass die Fingerprint-Funktionalität falsch angewandt wird oder es noch an einer Vorschrift/Standard fehlt, dass die Fingerprint-Funktion entweder nur in den physischen Modulen oder eben nur in den logischen Modulen vorhanden sein darf.
Wer kann helfen ? Müssen Module angepasst werden ?
Danke&Grüße
Markus