Not enough credit! - Ich bekomm es nicht hin.

Begonnen von Bartsi, 26 Februar 2017, 21:57:31

Vorheriges Thema - Nächstes Thema

Bartsi

Moin moin,

ich habe nun meine komplette FHEM installation neu gemacht um alten Müll nicht mehr zu haben. Leider habe ich mit meinen MAX Komponenten nun ärger ohne ende.
Ständig habe ich:
CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 86, but we need 113. Waiting 27 seconds. Currently 1 messages are waiting to be sent.

Im Regelfall habe ich max. 8 credits :-/

Komponenten sind vorhanden:
- 7x HT
- 4x Fensterkontakte
- 2x fakeWT mittels JeeLink Thermostate
- 1 Max CUBE mit a-culfw

Das ganze läuft auf einem RPI 2 mit CC1101 Modul für HM.

Sind es zu viele Komponenten, oder übersehe ich was?

Danke für eure Anregungen.

rubbertail

Pro Sekunde kriegst du einen Credit gutgeschrieben - sobald ein Befehl rausgeht, verbraucht der wieder welche. Tipp daher: Ein Wochenende fürs Pairing vorhalten, erstmal nur pairen. Nach jedem Pairing 15min warten. Wenn alles gepairt ist, einzeln die Wochenprogramme übertragen, dazwischen auch jeweils 15min warten. Und erst dann irgendwelche Befehle über notifies oder doifs rausjagen.
FHEM auf Raspi, CUL433, CUL868, RFXTRX433e, CULCuBE
FRITZ: Fritzbox7590AX, 6xFritzDECT301, 10xFritzDECT200, FritzRepeater 6000
MAX!: Fensterkontakte
netatmo: Wetterstation & Thermostat
Milights, IT, Withings, HUE

Wzut

Zitat von: Bartsi am 26 Februar 2017, 21:57:31
Sind es zu viele Komponenten, oder übersehe ich was?
Zu viele : nein (ich habe einiges mehr und keine Probs)
übersehen : schau dir mal die RSSI Werte deiner MAX Geräte an, wenn da ein Gerät im Grenzbereich der Reichweite liegt
fressen dir die permanenten Wiederholungen die kostbaren Credits (war bei mir bei einem Device so)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Bartsi

Huhu,

danke für den Tip mit dem Empfang. Ich hatte die "Anlage" nun über 2 Jahre ohne Probleme laufen. Jetzt nach dem "neueinrichten" fällt mir auf das die Empfangswerte mehr als nur bescheiden sind. Obwohl sich an den Positionen der Geräte nix geändert hat.

Ich werde heute Abend den CuBe mal via USB direkt an den Raspi klemmen statt per LAN im Keller. Mal schauen ob ich damit auf dem kurzen Dienstweg die Probleme beseitigen kann.

Vielen dank :-)

Wzut

Da du ja einen Cube mit a-culfw benutzt kennst du auch das innere Desgin des Cubes , d.h der kleine Antennendraht "steht" im Gehäuse.
Nachdem was ich hier im Forum schon alles über Antennen gelesen habe ist diese Anordnung gut für waagerechtes Senden/Empfangen (typisch wenn man im gleichen Stockwerk bleibt) du schreibst du hast den Cube in den Keller verbannt, d.h. nun wäre ein Mix aus senkrecht und waagerecht angebracht.
Teste doch mal wie sich deine RSSI Werte ändern wenn du den Cube schräg stellst oder aber ganz auf die Seite legst.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

scuba

Du kannst der a-culfw natürlich auch mehr "Credits" geben.

In der Datei culfw/clib/rf_send.h Zeile 18 findest du folgenden Eintrag:  ##define MAX_CREDIT 900       // max 9 seconds burst / 25% of the hourly budget
Hier einfach den Wert ändern und neu flashen. 3600 wäre das max. erlaubt; es geht aber natürlich auch mehr.

Bei ständigen Wiederholungen werden die 3600 natürlich auch bald "aufgefressen" sein. Also solltest du besser die Ursache rausfinden.
Wenn du den Wert zu hoch setzt beeinträchtigt das eventuell auch deinen HM Kommunikationsweg.

Bartsi

#6
Huhu,

folgendes habe ich nun getestet:
- Position verändert - Keller -> EG
- Schräg gestellt
- Deaktivieren der ExtSendTemp via fakeWT in 2 Räumen

Witziger weise sind die RSSI werte meines dafürhaltens immer noch bescheiden. Und er rennt immer noch ständig in einen out of Credits.
Für eine Übersicht habe ich versucht https://forum.fhem.de/index.php/topic,62184.15.html einzubinden. Jedoch zeigt er mir nur einzelnd die HM Geräte an nicht die MAX.

@scuba
Gelesen habe ich dies natürlich auch schon. Jedoch ist es dafür notwenig die Firmware zu compilieren. Und das bekomm ich auf meinem rpi nicht hin.

Ungeachtet der tatsache das das MAX_CREDIT verändern ein Thema für sich ist, möchte ich versuchen die Ursache einzugrenzen jedoch bisher ohne erfolg.


EDITH sagt:
13:34 Update

Ich habe mir nun mit stateFormat beholfen und erstaunliches entdeckt. Siehe Anhang.
KUE_Hz bekommt nicht mehr oder weniger mitgeteilt als andere HT. Dennoch scheint da der Hund begraben wenn ich mir die MSGCNT anschaue.

Bartsi

Soooo nach lange Testen ein Update.

Folgendes ist passiert.
Nachdem es nicht aufgehört hat mit den credit habe ich alle HT´s mittels fhem in factory reset gebracht, und in fhem auf ignore gesetzt. Danach war natürlich ruhe und die Bude eis kalt :-) Danach habe ich den HT in der Küche neu gepaired mit fhem und erstmal laufen lassen (2 Stunden). credit10ms mitgeplottet und mittels Plot frontend beobachtet.

Alles ruhig! Credit immer schön bei 900.
Im nächsten schritt habe ich erstmal versucht den HT mittels LaCrosse externe Temperaturen mitzuteilen. Natürlich habe ich das assozierien mit dem fakeWallThermostat vergessen (man(n) macht es 10 mal und glaubt den ablauf aus dem WIKI im Kopf zu haben und dann passiert genau sowas!) und gewundert warum ich ständig Missing ACKs bekomme nach einem "set CUL_MAX fakeWT KUE_Hz 21.0 19.1".

Ein nachträgliches "set KUE_Hz associate fakeWallThermostat" hat zur folge das ich im log ständig ein "Unhandled message WakeUp" vom HT empfange und die Credits in den Keller gehen.

Morgen werde ich den HT noch mal entfernen mittels reset und die Reihenfolge aus dem WIKI berücksichtigen. Mal schauen ob es funktioniert.

Gruß Kai

PS: Bitte um nachsehen der Rechtschreibung - bin irgendwie durch.