BridgeRegexp zu eigenem MQTT Modul (oder alternativen)

[Qowy]

Hi,
ich kann programmieren bin also durchaus gewillt im perl code rumzufummeln.

Ich habe ein BLE device das ManufProfile Pakete schickt, die Signatur sequence numbers etc haben.
Da es vermutlich etwas schwer wird AES Encryption mit Readings zu implementieren dachte ich, ich versuche mich daran ein eigenes MQTT2 .pm zu schreiben für das Gerät.

Ich habe schon einen MQTT2 client der mir die BLE Inhalte per MQTT empfängt (einen Shelly) und dann per BridgeRegexp weiterleitet.

Ich stehe nur etwas auf dem Schlauch wie ich jetzt die Daten in einem neuen Modul verarbeiten würde.

Kann ich irgendwie MQTT2_DEVICE "erweitern" und sowas wie ein "onData" Methode verwenden um perl auszuführen und dann die readings zu setzen.
Oder muss ich komplett einen eigenen MQTT Client schreiben, der die FHEM MQTT funktionen verwendet.

[Beta-User]

Kann ich irgendwie MQTT2_CLIENT "erweitern" und sowas wie ein "onData" Methode verwenden um perl auszuführen und dann die readings zu setzen.

RHASSPY z.B. macht sowas, man muss halt clientOrder bei MQTT2_CLIENT anpassen und eine dispatch-Funktion haben.

ABER:
Was spricht dagegen, MQTT2_DEVICE zu verwenden und in der readingList die Payload schlicht an eine myUtils-Routine zu übergeben?

[Qowy]

Was spricht dagegen, MQTT2_DEVICE zu verwenden und in der readingList die Payload schlicht an eine myUtils-Routine zu übergeben?

Hmm hatte ich jetzt garnicht auf dem Schirm dass das geht, ich hatte myutils bis jetzt immer als "ausgehenden" Code für Http requests oder Farbberechungen etc. verwendet.
Wenn ich da aber natürlich auch einfach arbitrary perl code machen kann und readings setzen könnte das natürlich auch klappen.
Ich werde mir das und das RHASSPY Beispiel mal anschauen, danke.

EDIT: Ich meinte ursprügnlich auch MQTT_DEVICE zu erweitern um eben alle vorhandene Funktionalität nicht zu doppeln. Aber readingList zu myUtils wäre ja fast genau das.

[Beta-User]

EDIT: Ich meinte ursprügnlich auch MQTT_DEVICE zu erweitern um eben alle vorhandene Funktionalität nicht zu doppeln. Aber readingList zu myUtils wäre ja fast genau das.

RHASSPY ist "nur" deswegen ein eigenes Modul, weil es zum einen zusätzlich diverse HTTP-requests absetzt, und zum anderen FHEM-installationsweite Optionen zur Verfügung stellt (Attribute für andere Devices).

Vielleicht schaust du dir mal das attrTemplate "wled_controller" an bzw. den betreffenden Diskussionssthread (https://forum.fhem.de/index.php?topic=98880.0).

Das verwendet sowohl in der readingList wie in setList eigene Routinen.

Irgendwo gab es auch mal einen Thread bzgl. der alten Shelly, die der TE dann z.T. zusätzlich auch via HTTP-requests angesteuert hatte, soweit ich mich entsinne. (Falls du zusätzlich auch noch sowas brauchen solltest).