Not enough Credits-Problem

[walterschmitz]

Hallo zusammen,

ich habe aktuell in der Log folgende Einträge vermehrt:

Code: [Auswählen]

2017.08.17 09:30:40 2 : CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 113. Waiting 110 seconds. Currently 22 messages are waiting to be sent.
Tendenz steigend für die currently xy Messages :-(

Einfach abwarten, bis die Messages verschickt wurden und die Credits wieder da sind, wird ja nicht funktionieren.

Ich habe das Gefühl, das im Haus andere auch ein ähnliches System einbauen und damit mir die Credits verbrauchen - weil mein Raspi / FHEM die mitschneidet.
Ich habe schon gesehen, dass 1 oder 2 neue Devices gefunden wurden.
Daher... muss ich vermutlich Autocreate ausstellen, oder?

Und jetzt funken die natürlich auch auf meinem Bereich, den ich aber ja auch nicht ändern kann... die Geräte lassen sich ja nicht einfach auf andere Kanäle umstellen :-( (z.B. wie im WLAN). Habe im EventMonitor / Log gesehen, dass dort Missing ACK drin steht und Geräte, die keinen REAL-Namen haben, sondern nur die MAX_ID... und die gibt es bei mir eigentlich nicht mehr, weil ich alle direkt umbenannt habe.
Ich könnte jetzt grundsätzlich diese Geräte mit MAX_ID erstmal auf Ignore setzen... aber würde das das Problem beheben?
Und würde mir natürlich auch nicht die DB oder FILELOG zumüllen... mit Daten ich nie brauche, es sei denn, ich möchte mal sehen, wie warm es beim Nachbarn ist :-P

Und meine weitere Idee: ein Notfiy bauen, dass bei einem Missing ACK evtl. ausgelöst wird. Damit würde ich ja sofort mitbekommen, dass ein neues Element eingetragen wurde, wenn ich die AutoCreate mal aktiv hätte und das würde mir ein solches Problem erzeugen... und ich kann es direkt auf ignore setzen. Wenn... was würde man in einem solchen Notify filtern? nur das "missing ACK" oder noch was anderes? Oder sollte ich lieber das "Not enoug Credtis" notifyen?

Wäre das die richtige Herangehensweise? Oder lieber andere Maßnahmen machen? Oder lieg ich mit meinen Überlegung evtl. grundsätzlich falsch?

Gruß

[cbl]

Ich habe seit wenigen Wochen  das ähnliche Phänomen. Mein Verdacht geht aber in die Richtung des "off"-Modus der Thermostate, da ich ungefähr zur selben Zeit alle Thermostate auf "off" gesetzt habe. (Es ist mein erster Sommer mit den Dingern.) Seitdem treiben die unversandten Messages den Zähler in die Höhe.
Was kann ich dagegen tun?

Gruß
Christian

[walterschmitz]

ich habe mittlerweile

Code: [Auswählen]

Currently 87 messagesDa brauch ich eigentlich gar keine Messages oder Actions abgegeben. Die werden sowieso nicht mehr ankommen, zumindest nicht in ausreichender Zeit.

Ausser meinen eigenen Device hab ich jetzt auch alle anderen auf Ignore gesetzt... trotzdem scheint sich die Situation nicht zu bessern :-(

Hat denn hier wirklich niemand eine Idee.

[Wzut]

warum hast du autocreate auf on  ? Kommen bei dir ständig neue Geräte dazu ??
Vermutlich nicht , aber defekte Telegramme erzeugen wunderbare Fake Geräte und die vergebliche Kommunikation mit diesen Geräten verbrät dir die kostbaren Credits.
Also, attr autocreate disable 1 und Leichen löschen. Wenn ein neues Gerät ins System soll das attr disable löschen , Gerät einbinden lassen und sofort danach wieder attr autocreate disable 1 setzen.

[walterschmitz]

Hallo,

vielen Dank für deine Antwort.
Hab ich gemacht... Autocreate ist OFF bzw. ignored!

Mal schauen, ob es was bringt.

Danke dir für den Hinweis.

Gruß

[walterschmitz]

Hallo zusammen,

ich habe jetzt mal ein Update gemacht, danach ein shutdown restart und mir dann die LOG-File angeschaut.
Irgendwie läuft FHEM gerade nicht mehr rund :-( Warum weiß ich ehrlich gesagt noch nicht so richtig... Hauptproblem sind die not enough credits...

Vielleicht könnt ihr mir helfen, wie ich den Laden wieder ans Laufen bekomme!
Auszug aus der Log-File:

Code: [Auswählen]

2017.09.23 22:32:05 0: Server shutdown
2017.09.23 22:32:07 1: Including fhem.cfg
2017.09.23 22:32:07 3: telnetPort: port 7072 opened
2017.09.23 22:32:07 3: WEB: port 8083 opened
2017.09.23 22:32:07 3: WEBphone: port 8084 opened
2017.09.23 22:32:07 3: WEBtablet: port 8085 opened
2017.09.23 22:32:08 2: eventTypes: loaded 497 events from ./log/eventTypes.txt
2017.09.23 22:32:08 3: Opening CUL433 device /dev/ttyACM0
2017.09.23 22:32:08 3: Setting CUL433 serial parameters to 9600,8,N,1
2017.09.23 22:32:08 3: CUL433: Possible commands: BbCFiAZEkGMKUYRTVWXefmltux
2017.09.23 22:32:08 3: CUL433 device opened
2017.09.23 22:32:08 3: Opening CUL868 device /dev/ttyACM1
2017.09.23 22:32:08 3: Setting CUL868 serial parameters to 9600,8,N,1
2017.09.23 22:32:08 3: CUL868: Possible commands: BbCFiAZEkGMKUYRTVWXefmltux
2017.09.23 22:32:08 3: CUL868 device opened
2017.09.23 22:32:08 2: Switched CUL868 rfmode to MAX
2017.09.23 22:32:08 3: Opening ZWDongle device /dev/ttyACM2
2017.09.23 22:32:08 3: Setting ZWDongle serial parameters to 115200,8,N,1
2017.09.23 22:32:09 3: ZWDongle device opened
2017.09.23 22:32:09 1: PERL WARNING: Argument "01 CUL868 (F-Band:" isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 145, <$fh> line 35.
2017.09.23 22:32:09 3: CUL_MAX_Check: Detected firmware version 164 of the CUL-compatible IODev
2017.09.23 22:32:10 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
2017.09.23 22:32:11 1: Including ./log/fhem.save
2017.09.23 22:32:11 3: No I/O device found for WoZi.WT
2017.09.23 22:32:11 3: No I/O device found for ScZi.WT
2017.09.23 22:32:11 1: usb create starting
2017.09.23 22:32:11 3: Probing CUL device /dev/ttyAMA0
2017.09.23 22:32:12 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.09.23 22:32:12 3: Probing ZWDongle device /dev/ttyAMA0
2017.09.23 22:32:12 3: Probing FRM device /dev/ttyAMA0
2017.09.23 22:32:17 1: usb create end
2017.09.23 22:32:17 0: Featurelevel: 5.8
2017.09.23 22:32:17 0: Server started with 70 defined entities (fhem.pl:15112/2017-09-21 perl:5.020002 os:linux user:fhem pid:23048)
2017.09.23 22:32:17 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2017.09.23 22:32:17 3: FHEMWEB WEB CSRF error: csrf_163014933084691 ne csrf_401758714109582 for client WEB_192.168.178.32_52071. For details see the csrfToken FHEMWEB attribute.
2017.09.23 22:32:27 3: FHEMWEB WEB CSRF error: csrf_163014933084691 ne csrf_401758714109582 for client WEB_192.168.178.32_52071. For details see the csrfToken FHEMWEB attribute.
2017.09.23 22:32:39 3: FHEMWEB WEB CSRF error: csrf_163014933084691 ne csrf_401758714109582 for client WEB_192.168.178.32_52072. For details see the csrfToken FHEMWEB attribute.
2017.09.23 22:32:40 1: PERL WARNING: Argument "01 CUL868 (F-Band:" isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 145.
2017.09.23 22:32:40 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 59, but we need 113. Waiting 54 seconds. Currently 1 messages are waiting to be sent.
2017.09.23 22:33:36 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 113. Waiting 110 seconds. Currently 1 messages are waiting to be sent.
Aufgefallen dabei sind mir die folgenden Zeilen:

Code: [Auswählen]

2017.09.23 22:32:09 1: PERL WARNING: Argument "01 CUL868 (F-Band:" isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 145, <$fh> line 35.
(...)
2017.09.23 22:32:40 1: PERL WARNING: Argument "01 CUL868 (F-Band:" isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 145.Hier wurde alles über FHEM eingetragen und eingerichtet... eine Änderung daran hab ich aktiv nicht vorgenommen... finde aber auch den Eintrag nicht, wo ein nicht-numerischer Wert eingetragen sein soll. Wo muss ich hier detailierter nachschauen?
Ausserdem deutet sich hier der Fehler in einer Datei 14_CUL_MAX.pm an, an der ich aktiv noch nie dran war. Ich wüsste ehrlich gesagt auch gar nicht, was ich daran ändern sollte. Und von daher lass ich von sowas auch die Finger!

Code: [Auswählen]

2017.09.23 22:32:10 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabledDer Hinweis war früher auch nicht drin. Muss ich hier aktiv werden, um was in den Einstellungen zu ändern?

Code: [Auswählen]

2017.09.23 22:32:11 3: No I/O device found for WoZi.WT
2017.09.23 22:32:11 3: No I/O device found for ScZi.WTHat auch funktioniert, bevor ein Update gemacht wurde... wobei bei beiden die Batterien ausgetauscht wurden. Kann es auch daran liegen?
Und das Problem... einfach neu Associaten funktioniert auch nicht, wegen den Not enough credits (siehe nächster Hinweis).

Code: [Auswählen]

2017.09.23 22:32:40 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 59, but we need 113. Waiting 54 seconds. Currently 1 messages are waiting to be sent.
2017.09.23 22:33:36 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 113. Waiting 110 seconds. Currently 1 messages are waiting to be sent.
Und das wundert mich halt vor allem. Direkt nach dem Starten sind Currently 1 messages in der Warteschleife? Nach 2-3 Tagen steht dort 260 messages. Damit kann man ja auch nicht wirklich arbeiten (lassen). Ich habe schon AUTOCREATE disabled, wie man empfohlen hat... hat aber keine Besserung gebracht.
Übrigens... wenige Minuten später habe ich schon 4 in der Warteschlage. Jetzt können wir hochrechnen, wann ich wieder ungefährt bei 200 messages wäre :-(

Code: [Auswählen]

2017.09.23 22:44:52 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 113. Waiting 110 seconds. Currently 4 messages are waiting to be sent.
2017.09.23 22:46:44 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 113. Waiting 110 seconds. Currently 3 messages are waiting to be sent.


Code: [Auswählen]

2017.09.23 22:32:17 3: FHEMWEB WEB CSRF error: csrf_163014933084691 ne csrf_401758714109582 for client WEB_192.168.178.32_52071. For details see the csrfToken FHEMWEB attribute.Ist das ein neues Attribute?
Ich habe einmal das Update über die App ausgeführt... da hab ich die Meldungen leider nicht angezeigt bekommen :-(
Das sind die Meldungen nach dem Update soeben... und einem Neustart.
Ich denke, damit muss ich erst einmal anfangen, bevor ich weitersuche.
Vielleicht hängte das ja alles irgendwie zusammen und dadurch werden Messages nicht sauber übertragen und erzeugen dann sekundär die Probleme.

Wäre schön, wenn ihr mir helfen könntet und würdet. So langsam weiß ich halt nicht mehr, wo ich ansetzen sollte.

Danke im Voraus!

Gruß

[Wzut]

2017.09.23 22:32:08 3: Opening CUL433 device /dev/ttyACM0
2017.09.23 22:32:08 3: Opening CUL868 device /dev/ttyACM1
2017.09.23 22:32:10 3: ZWave: cannot load Crypt::Rijndael, SECURITY class disabled
2017.09.23 22:32:17 3: FHEMWEB WEB CSRF error: csrf_163014933084691 ne csrf_401758714109582 for client WEB_192.168.178.32_52071. For details see the csrfToken FHEMWEB attribute.

a. zwei Culs und dann beide direkt via /dev/ttyACMx . Schlechte Wahl ! Vermutlich haben die beiden ihre ACM Zuordnung getauscht und du fährst nun den 433 Cul mit MAX. Dabei ist aber der Empfang so grottenschlecht das das mit Sicherheit nix wrd. Such im Forum nach /dev/serial/by-id/ - dann hast das Problem schon mal vom Hals
b. Zwave : laut command.ref wird Crypt::Rijndae benötigt. Ist nicht das einzige Modul, durchsuch die command.ref Seite nach Rijndae , bei einem der Treffer steht auch wie man es mittels CPAN installiert.
c. durchsuch das Forum entweder nach csrfToken (das gibt verdammt viele Treffer) oder lies einfach endlich mal was ganz oben rechts seit Ewigkeiten auf jeder Seite in Rot da steht.

[walterschmitz]

zwei Culs und dann beide direkt via /dev/ttyACMx . Schlechte Wahl ! Vermutlich haben die beiden ihre ACM Zuordnung getauscht und du fährst nun den 433 Cul mit MAX. Dabei ist aber der Empfang so grottenschlecht das das mit Sicherheit nix wrd. Such im Forum nach /dev/serial/by-id/ - dann hast das Problem schon mal vom Hals

Hab ich gemacht... vielen Dank für den Tipp... aber geändert hat sich dadurch nichts.
Ist das gleiche Phänomen wie zuvor...

Mich wundert nur... bis zu einem Zeitpunkt X ging es halt... aber grundsätzlich hast du ja recht. So ist es eindeutig und kann nicht mehr verwechselt werden!

2017.09.23 22:32:09 1: PERL WARNING: Argument "01 CUL868 (F-Band:" isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 145, <$fh> line 35.

Mich würde aber eher das Problem interessieren, weil das auch immer noch besteht... und vor allem in Bezug auf den CUL 868 existiert. Und das ist ja der CUL, welcher für die MAX da ist und somit ja auch Probleme macht.
Wie kann ich CUL-MAX da beibringen, dass dieser Fehler behoben ist / wird?

[Wzut]

schade, die Theorie mit den vertauschten CULs hatte so schön in die Logik gepasst.
Zu deiner Fehlermeldung : Schaut man sich in 14_CUL_MAX mal die Zeile 145 an, so sieht man das dort versucht wird
den Versionsstring ( Rückgabe beim Kommando V) zu zerlegen. Bei meinem Uralt original CUL steht unter INTERNALS VERSION : V 1.60 CUL868
Bei den Cubs mit der a-culfw sieht der String schon etwas anders aus , Bsp

Code: [Auswählen]

V 1.10.02 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)Du siehst da taucht auch der F-Band Schippel auf , aber halt wesentlich weiter hinten im String.
Was genau gibt denn dein 868 bei V zurück ?

[walterschmitz]

Code: [Auswählen]

CUL868 version => V 1.63.01 CUL868 (F-Band: 868MHz)Meinst du diese Ausgabe, die ich bekommen, wenn ich beim CUL868  das

Code: [Auswählen]

Get version über FHEM ausführe?

Ich wüsste hier leider nicht, was ich da ändern kann?

[walterschmitz]

fällt denn hier wirklich niemanden was ein, was ich ändern kann, um
1.) Die Fehlermeldung

Code: [Auswählen]

2017.09.23 22:32:09 1: PERL WARNING: Argument "01 CUL868 (F-Band:" isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 145, <$fh> line 35. wegzubekommen und
2.) das Credits-Problem zu beheben.
Aktuell haben wir ca. 680 wartende Elemente :-(

[walterschmitz]

Die LOG-File wird immer schlimmer.

Code: [Auswählen]

2017.10.05 21:35:45 3: CUL_MAX_Parse: Pairing device 16d037 of type HeatingThermostatPlus with serial NEQ1016748
2017.10.05 21:35:50 3: CUL_MAX_Parse: Pairing device 16d037 of type HeatingThermostatPlus with serial NEQ1016748
2017.10.05 21:35:55 3: CUL_MAX_Parse: Pairing device 16d037 of type HeatingThermostatPlus with serial NEQ1016748
2017.10.05 21:36:00 3: CUL_MAX_Parse: Pairing device 16d037 of type HeatingThermostatPlus with serial NEQ1016748
2017.10.05 21:36:05 3: CUL_MAX_Parse: Pairing device 16d037 of type HeatingThermostatPlus with serial NEQ1016748
2017.10.05 21:36:10 3: CUL_MAX_Parse: Pairing device 16d037 of type HeatingThermostatPlus with serial NEQ1016748gestern abend habe ich extra ein Element neu gepaired, weil es mit Missing ACK eingetragen war. Warum der das mehfach macht und nicht repaired schreibt, obwohl er schon im FHEM drin war, kann ich nicht nachvollziehen. Bei anderen steht es dann meist re-paired.

Heute dann ohne Änderung wieder solche Meldungen

Code: [Auswählen]

2017.10.06 00:53:26 2: CUL_MAX_SendQueueHandler: Missing ack from 16d037 for 0fd0040312345616d03700110600b597Verstehen, warum... muss ich das nicht, weil gestern abend ja alles wieder mit diesem Device laufen sollte.

und seit heute morgen dann bislang nicht aufgetretene Meldungen...

Code: [Auswählen]

2017.10.06 05:03:05 3: CUL868: Unknown code Z020E22, help me!
2017.10.06 05:03:05 2: CUL_MAX_Parse: Got unhandled message type D0
2017.10.06 05:03:10 3: CUL868: Unknown code Z05030E1D4F12, help me!
2017.10.06 05:03:15 3: CUL868: Unknown code Z00, help me!
2017.10.06 05:03:20 3: CUL868: Unknown code Z058388F98A0F, help me!
2017.10.06 05:03:39 3: CUL868: Unknown code Z030E1D4F, help me!
2017.10.06 05:03:39 2: CUL_MAX_Parse: Got unhandled message type 06
2017.10.06 05:04:29 2: CUL_MAX_Parse: Got unhandled message type 1D
2017.10.06 05:04:34 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 113. Waiting 105 seconds. Currently 18 messages are waiting to be sent.
2017.10.06 05:04:44 2: CUL_MAX_Parse: Got unhandled message type 34
2017.10.06 05:04:44 2: CUL_MAX_Parse: Got unhandled message type D5
2017.10.06 05:04:55 3: CUL868: Unknown code Z020E22, help me!
2017.10.06 05:04:55 3: CUL868: Unknown code Z00, help me!
2017.10.06 05:05:00 3: CUL868: Unknown code Z00, help me!
2017.10.06 05:05:00 3: CUL868: Unknown code Z040CF50442, help me!
2017.10.06 05:05:31 2: CUL_MAX_Parse: Got unhandled message type 5F
2017.10.06 05:05:31 2: CUL_MAX_Parse: Got unhandled message type 5F
2017.10.06 05:06:21 2: CUL_MAX_Parse: Got unhandled message type 56
2017.10.06 05:06:27 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 113. Waiting 105 seconds. Currently 18 messages are waiting to be sent.
2017.10.06 05:06:33 2: CUL_MAX_Parse: Got unhandled message type 0E
2017.10.06 05:06:33 2: CUL_MAX_Parse: Got unhandled message type 4A
2017.10.06 05:07:42 2: CUL_MAX_Parse: Got unhandled message type 1D
2017.10.06 05:07:42 2: CUL_MAX_Parse: Got unhandled message type D0
2017.10.06 05:07:48 2: CUL_MAX_Parse: Got unhandled message type D0
2017.10.06 05:07:52 2: CUL_MAX_Parse: Got unhandled message type D1
2017.10.06 05:08:14 2: CUL_MAX_Parse: Got unhandled message type 19
2017.10.06 05:08:16 2: CUL_MAX_SendQueueHandler: Missing ack from 0e226f for 0fbf04031234560e226f00110605888d
2017.10.06 05:08:16 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 5, but we need 113. Waiting 108 seconds. Currently 17 messages are waiting to be sent.
2017.10.06 05:08:22 1: PERL WARNING: Use of uninitialized value $type in concatenation (.) or string at ./FHEM/14_CUL_MAX.pm line 343.
2017.10.06 05:08:22 1: PERL WARNING: Use of uninitialized value $testresult in concatenation (.) or string at ./FHEM/14_CUL_MAX.pm line 343.
2017.10.06 05:08:22 1: PERL WARNING: Use of uninitialized value $serial in concatenation (.) or string at ./FHEM/14_CUL_MAX.pm line 343.
2017.10.06 05:09:19 3: CUL868: Unknown code Z020E22, help me!
2017.10.06 05:09:54 2: CUL_MAX_Parse: Got unhandled message type 4F
2017.10.06 05:10:07 3: CUL868: Unknown code Z020000, help me!
2017.10.06 05:10:12 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 8, but we need 113. Waiting 105 seconds. Currently 17 messages are waiting to be sent.
2017.10.06 05:10:25 3: CUL868: Unknown code Z0313D018, help me!
2017.10.06 05:10:25 2: CUL_MAX_Parse: Got unhandled message type 06
2017.10.06 05:10:30 2: CUL_MAX_Parse: Got unhandled message type D0
2017.10.06 05:10:35 2: CUL_MAX_Parse: Got unhandled message type D0
2017.10.06 05:10:36 2: CUL_MAX_Parse: Got unhandled message type D0
Und... immer wieder die CUL_MAX.pm neben den ganzen anderen Meldungen.

Ich habe keine Ahnung mehr, wo ich nach dem Fehler suchen soll. neu aufsetzen will ich nicht, weil ich sonst die ganzen anderen Elemente auch neu einrichten muss und irgendwie hängt es immer nur am MAX bzw. CUL_MAX. Das muss doch irgendwie eingrenzbar sein :-(

[walterschmitz]

Hallo zusammen,

mal ne blöde Frage... eher unwahrscheinlich... aber trotzdem
Könnte der CUL bei sowas auch defekt sein?
Mir kommt das ganze schon etwas spanisch vor. Habe jetzt auch die Logging Einstellungen mal auf detailierter eingestellt, und da sieht es regelmässig nicht nach Fehlern aus... jedoch immer die CreditsProbleme.
Könnte ein Defekt des CUL dafür auch der Grund sein?

Es erscheint mir so, als würde der CUL die 1%-Regelung nicht einhalten, die Geräte aber sauber miteinander arbeiten (z.B: Fenster auf, Temp am HT runter) usw. Daher kann ich eigentlich nur noch vermuten, dass der CUL einen Schaden hat.
Firmware ist aktuell neu aufgespielt --> keine Änderung
FHEM ist aktualisiert --> keine Änderung

Mehr kann man ja eigentlich nicht mehr wirklich machen.

Gerne stelle ich auch noch die detailiertere Log zur Verfügung... Glaube aber auch nicht wirklich daran, dass man da was finden könnte.

Gruß

[Wzut]

Sicher der CUL ist auch nur Hardware und da kann auch mal was sterben.
Ich persönlich würde da aber erst einmal einen anderen Weg gehen.
a. FHEM stoppen
b. die aktuelle fhem.cfg unter einem anderen Namen sichern und die fhem.save umbenennen.
c. alles an zusätzlicher Hardware ausser dem 868 CUL entfernen
e. fhem mit einer absoluten mini config starten.
f.  nachdem FHEM jungfräulich oben ist  : den CUL definieren
g. das cm Device anlegen
h. ein MAX! HT aus der Original fhem.cfg von Hand anlegen
f. schauen was die Credits machen und ob du erfolgreich Kommandos an das HT absetzen kannst

[Tedious]

Gute Idee, kleine Anmerkung: FHEM Service stoppen, ein Docker-Image mit FHEM einspielen, CUL durchreichen und anmelden. Denn wie vorgeschlagen. Wenns funktioniert das Image wieder löschen ud FHEM wieder starten Weniger Fehleranfällig