Was bedeutet "Not enough credit!"?

[stobor]

Hallo,
was bedeutet die Meldung "Not enough credit! ..." und wie kann/muss ich das beheben?

Code Auswählen Erweitern


2016.05.28 21:38:32 2: CUL_MAX_SendQueueHandler: Missing ack from 0a5ec8 for 0f4404031234560a5ec800101c15665c
2016.05.28 21:38:32 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 101, but we need 113. Waiting 12 seconds.
2016.05.28 21:38:50 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 113. Waiting 106 seconds.
2016.05.28 21:40:43 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 113. Waiting 107 seconds.
2016.05.28 21:42:36 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 113. Waiting 106 seconds.
2

Vielen Dank für eure Hilfe.

[traveltheworld]

Siehe 1%-Regel für private Funk-Nutzung.

Wenn die Meldung kommt, heißt das somit, dass ein zu versendendes Paket aufgrund dieser Regel warten muss.
Anders gesagt, du versuchst aus welchem Grund auch immer zuviele Befehle in zu kurzer Zeit zu versenden.

Du kannst verbose im Cul_max auf 5 setzen, dann siehst du genau die Befehle.

[stobor]

Ich habe da jetzt so etwas gefunden:

Code Auswählen Erweitern


2016.05.28 23:31:27 1: Error in CUL_MAX_SendQueueHandler: CUL CUL_1 did not answer request for current credits. Waiting 5 seconds.
2016.05.28 23:31:32 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.28 23:31:32 1: CUL_MAX_Check: No IODev has no VERSION
2016.05.28 23:31:32 5: SW: X
2016.05.28 23:31:32 1: Error in CUL_MAX_SendQueueHandler: CUL CUL_1 did not answer request for current credits. Waiting 5 seconds.
2016.05.28 23:31:36 5: CUL/RAW: /H8725001262561C


Aber was bedeutet das? Ich tracke nur dem MAX! Datenverkehr, sende aber selber nicht.

[stobor]

Oder hilft dieser Logeintrag mehr?

Code Auswählen Erweitern


2016.05.29 00:43:14 5: CUL_MAX_BroadcastTime: payload 101d006b4e
2016.05.29 00:43:14 5: Broadcast time to 097d7b
2016.05.29 00:43:14 5: CUL_MAX_Send: enqueuing 0f360403123456097d7b00101d006b4e
2016.05.29 00:43:14 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 00:43:14 5: SW: X
2016.05.29 00:43:14 5: CUL/RAW (ReadAnswer): 21  900

2016.05.29 00:43:14 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 900
2016.05.29 00:43:14 5: Updating TimeInformation payload
2016.05.29 00:43:14 5: CUL_1 sending Zs0f360403123456097d7b00101d006b4e
2016.05.29 00:43:14 5: SW: Zs0f360403123456097d7b00101d006b4e
2016.05.29 00:43:14 5: Broadcast time to 016ee4
2016.05.29 00:43:14 5: CUL_MAX_Send: enqueuing 0f360403123456016ee400101d006b4e
2016.05.29 00:43:14 5: CUL_MAX_SendQueueHandler: 2 items in queue
2016.05.29 00:43:15 5: CUL_MAX_SendQueueHandler: 2 items in queue
2016.05.29 00:43:15 5: CUL_MAX_SendQueueHandler: 2 items in queue
2016.05.29 00:43:16 5: CUL_MAX_SendQueueHandler: 2 items in queue
2016.05.29 00:43:16 5: CUL_MAX_SendQueueHandler: 2 items in queue
2016.05.29 00:43:17 5: CUL_MAX_SendQueueHandler: 2 items in queue
2016.05.29 00:43:17 5: CUL_MAX_SendQueueHandler: 2 items in queue
2016.05.29 00:43:17 5: CUL_MAX_SendQueueHandler: Retry 097d7b for 0f360403123456097d7b00101d006b4e count: 3
2016.05.29 00:43:20 5: CUL_MAX_SendQueueHandler: 2 items in queue
2016.05.29 00:43:20 5: SW: X
2016.05.29 00:43:20 5: CUL/RAW (ReadAnswer): 21  793


Ich finde es wirklich komisch, da ich mit dem MAX!-Geräten über FHEM gar nichts anstelle, sondern nur horche, was die treiben, um deren Zustãnde anzuzeigen.

fhem.cfg:

Code Auswählen Erweitern


define initialUsbCheck notify global:INITIALIZED usb create
define CUL_0 CUL /dev/ttyACM0@9600 1034
define CUL_1 CUL /dev/ttyACM1@9600 1134
attr CUL_1 rfmode MAX

define cm CUL_MAX 123456
attr cm IODev CUL_1



Wäre das dann

Code Auswählen Erweitern

attr CUL_MAX verbose 5
oder

Code Auswählen Erweitern

attr CUL_1 verbose 5
?

[traveltheworld]

In deinem unterem Logauszug siehst du, was versucht wird zu senden, das sind die CUL_MAX_Send Einträge. Direkt daneben findest du die Broadcast Time Zeilen, d.h. Hier wird versucht, einem Thermostat die aktuelle Zeit zu senden.
Das ist ganz normal, sollte einmal stündlich passieren, je nach Anzahl deiner Thermostate 0-x Geräte pro Stunde (Anzahl modulo 6).

In deinem ersten Log sehe ich aber Fehlereinträge "Error in .." Und auch die ".. no version" Meldung, diese tauchen im späteren Log nicht mehr auf.  Das sieht nach einem nicht richtig verbundenem CUL aus.
Hat sich das erledigt? Wenn ja, sollten sich die zu versendenden Pakete langsam abbauen und dann auch die not enough credits Meldungen verschwinden.

Ansonsten sind die zwei verbose Settings genau richtig.

[stobor]

Ich hatte mal alles neu gestartet. Danach scheinen die Fehlermeldungen (Error in ... und ... no version) verschwunden zu sein.
Kann man das Senden der Zeit irgendwie unterbinden? Die MAX!-Geräte sind ja nicht mit FHEM gepaired. Sie laufen regulär über die MAX!-Cube, und die wird ja sicherlich auch die Zeit Syncen, oder? Ich möchte in FHEM rein lesend nur die Zustände anzeigen.

Im Log fiinde ich jetzt nur noch:

Code Auswählen Erweitern


2016.05.29 11:23:58 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 793
2016.05.29 11:23:58 5: Updating TimeInformation payload
2016.05.29 11:23:58 5: CUL_1 sending Zs0f410403123456097d7c00101d0b577a
2016.05.29 11:23:58 5: SW: Zs0f410403123456097d7c00101d0b577a
2016.05.29 11:23:58 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:23:59 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:23:59 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:00 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:00 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:01 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:01 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:01 5: CUL_MAX_SendQueueHandler: Retry 097d7c for 0f410403123456097d7c00101d0b577a count: 2
2016.05.29 11:24:04 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:04 5: SW: X
2016.05.29 11:24:04 5: CUL/RAW (ReadAnswer): 21  687

2016.05.29 11:24:04 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 687
2016.05.29 11:24:04 5: Updating TimeInformation payload
2016.05.29 11:24:04 5: CUL_1 sending Zs0f410403123456097d7c00101d0b5844
2016.05.29 11:24:04 5: SW: Zs0f410403123456097d7c00101d0b5844
2016.05.29 11:24:05 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:05 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:06 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:06 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:07 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:07 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:08 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:08 5: CUL_MAX_SendQueueHandler: Retry 097d7c for 0f410403123456097d7c00101d0b5844 count: 1
2016.05.29 11:24:11 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:11 5: SW: X
2016.05.29 11:24:11 5: CUL/RAW (ReadAnswer): 21  580

2016.05.29 11:24:11 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 580
2016.05.29 11:24:11 5: Updating TimeInformation payload
2016.05.29 11:24:11 5: CUL_1 sending Zs0f410403123456097d7c00101d0b584b
2016.05.29 11:24:11 5: SW: Zs0f410403123456097d7c00101d0b584b
2016.05.29 11:24:11 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:12 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:12 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:13 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:13 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:14 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:14 5: CUL_MAX_SendQueueHandler: 1 items in queue
2016.05.29 11:24:14 2: CUL_MAX_SendQueueHandler: Missing ack from 097d7c for 0f410403123456097d7c00101d0b584b
2016.05.29 11:26:16 5: CUL/RAW: /Z0CD70442016EE40A5EC8000AD307


Ist das noch etwas Bedenkliches?

Ich habe jetzt einmal die Heizungsthermostate in der fhem.cfg auskommentiert, da mich primär nur die Fensterkontakte interessieren.

[traveltheworld]

Log schaut i.O. aus.
Wenn du die Thermostate eh nicht über fhem steuerst und auch nicht wirklich mitlesen willst, dann ist das Auskommentieren dieser in der fhem.cfg eigentlich das Sauberste.
autocreate müßtest du dann wohl auch deaktivieren, sonst erscheinen sie wieder automatisch.

Mir ist keine Konfiguration zum Deaktivieren der Zeit-Updates bekannt, d.h. du müßtest dann direkt die entsprechende Zeile in 14_CUL_MAX.pm auskommentieren (Zeile 586: CUL_MAX_Send($hash, "TimeInformation", $addr, $payload, flags => "04").
Das wird beim nächsten Update aber wieder überschrieben, ist also keine saubere Lösung.

[stobor]

Wäre ja eigentlich super, wenn man das per Flag in der fhem.cfg ausschalten könnte, oder?
Kann man das irgendwie mit in die Roadmap aufnehmen? Wie?