Not enough Credits-Problem

Begonnen von walterschmitz, 17 August 2017, 09:39:25

Vorheriges Thema - Nächstes Thema

walterschmitz

#15
2 Frage dazu noch...

1.) Verliere ich beim Vorschlag 1 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
nicht die ganzen Pairings... wenn ich später die "alte" fhem.cfg wieder reinkopiere

und bei Vorschlag 2... was meinst du mit CUL durchreichen und anmelden

Ansonsten versuche ich das natürlich mal gern.
Die anderen beiden Dongle kann ich einfach abschalten.

walterschmitz

#16
Habe das ganze jetzt mal ausprobiert.

Nur 2 Devices angelernt... WT und HT.
Scheint momentan zu funktionieren.

Soll ich jetzt mal die anderen CUL aktivieren und einrichten oder lieber erst die anderen MAX-Devices?
oder wie sollte man weiter vorgehen...

Was auffällt... jetzt habe ich im EventMonitor viele von diesen Einträgen:
2017-10-22 14:38:17 Global global UNDEFINED MAX_0ee7af MAX WallMountedThermostat 0ee7af
2017-10-22 14:38:45 Global global UNDEFINED MAX_0eed4a MAX WallMountedThermostat 0eed4a
2017-10-22 14:39:31 Global global UNDEFINED MAX_0a10ee MAX WallMountedThermostat 0a10ee
2017-10-22 14:40:02 Global global UNDEFINED MAX_0a10ee MAX WallMountedThermostat 0a10ee
2017-10-22 14:40:15 Global global UNDEFINED MAX_13d018 MAX WallMountedThermostat 13d018


und im Logfile:
2017-10-22 14:41:09 Global global UNDEFINED MAX_0ee7af MAX WallMountedThermostat 0ee7af
2017.10.22 14:41:09 2 : Got message for undefined device 0e226f, and failed to guess type from msg 'Ack' - ignoring
2017.10.22 14:41:31 2 : Got message for undefined device 0e225f, and failed to guess type from msg 'Ack' - ignoring
2017.10.22 14:42:19 2 : Got message for undefined device 08d15f, and failed to guess type from msg 'Ack' - ignoring
2017.10.22 14:43:58 2 : Got message for undefined device 0e226f, and failed to guess type from msg 'Ack' - ignoring


ein Pairing diese Devices lässt sich momentan leider nicht durchführen...
CulMAX ist im PairingMode und das Device auch... es erscheint im Log bzw. EventMonitor aber KEIN Pairing.

Soviel zu den bislang gefundenen Eintragungen in Logfile und EventMonitor.

So ganz läuft es jetzt also doch noch nicht :-(

================
Nächster Nachtrag:
Ich bekomme bei einigen Devices KEIN Pairing hin :-(
Was kann man da machen bzw. wo könnten Einstellungen versteckt sein, wo Devices auf Ignoring stehen. Da würde ich dann mal nachschauen.

Wenn ich dann den Devices, dir mir sauber Werte liefern, aber Werte übertragen möchte, passiert folgendes:
2017-10-22 15:43:13 CUL CUL868 credit10ms: 581
2017-10-22 15:43:13 MAX ScZi.WT desiredTemperature 16.0
2017-10-22 15:43:15 Global global UNDEFINED MAX_13d018 MAX WallMountedThermostat 13d018
2017-10-22 15:43:20 CUL CUL868 credit10ms: 478
2017-10-22 15:43:26 CUL CUL868 credit10ms: 374
2017-10-22 15:43:32 CUL CUL868 credit10ms: 270
2017.10.22 15:43:35 2 : CUL_MAX_SendQueueHandler: Missing ack from 0ee7af for 0b0100402345670ee7af0060


Sprich... es werden in kurzer Zeit 3 Pakete übermittelt, die aber verloren gehen - das ACK schlägt fehl, was zum Fehlschlagen des Pairings passt.
Aber dadurch verliere ich natürlich bei den Credits beim Absetzen mehrerer Meldungen an einige Devices natürlich auch entsprechende Credits. Macht dann auch Sinn, dass sich das dann hochspielt bis zu 100.ten Credits-Meldungen und ausstehenden Messages.

Aber... wo könnten die noch auf Ignoring stehen, wäre mein nächster Suchansatz.

Wzut

mach dich mit dem Pairing nicht verrückt , IMHO ist das bei MAX! recht einfach gestrickt.
Entweder das Ding ist jungfräulich  (nach einem Werksreset) und kennt keinen Master oder es kennt einen und hat dessen ID im Hirn stehen.
D.h. solange du bei deinen Tests deine ID am cm Device ( das sind diese 6 Zeichen ) nicht änderst brauchst du kein neues Pairing !
Darum habe ich ja geschrieben, nimm zwei Geräte aus deiner alten config und lege sie so von Hand an. Alle anderen die fröhlich durch die Gegend funken wird autocreate nach und nach auch anlegen. Deine ganzen Fehler sehen für mich aus als ob dein CUL zwar fleissig Telegramme empfängt aber arge Probleme beim senden hat.
   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

hm... ich kann gerne auch nochmal neu anfangen, eine neue ID vergeben und bei den Geräte jeweils die Batterie rausnehmen bzw. sie auf Werkseinstellungen zurücksetzen.
Wenn du meinst, dass es was bringt?

Dann stellt sich nur die Frage... wie
Bei manchen WT kann ich nicht das Menü aktivieren um dann wieder auf Werkseinstellungen zu resetten. Evtl. geht das auch mit Batterie raus für längere Zeit, denke ich.

Oder meinst du, der CUL ist wirklich beschädigt?

Wzut

nein, nein kein Werksreset ! Warum willst du die gespeicherte ID löschen und dir ganze dann notwendige Arbeit ans Bein binden ?
Die WTs werden auch nicht über das Menü zurück gesetzt sondern mit Bat raus drei Knöpfe halten und Bat rein bis rRes im Display steht - gibt aber für die diversen Modelle entsprechende Anleitungen bei ELV.
Bist du auch zu 100% sicher das du deine ganzen Versuche mit dem richtigen CUL machst ?
Schon mal die beiden getauscht ? 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

Klar. Der identifiziert sich ja ID und ist der gleiche wie zuvor.
In diesem Fall würde ich sagen Ja ich bin mir sicher.  Könnte ein CUL433 denn auch die 868 empfangen ohne umzuprogrammieren?

Hab ich nicht gemacht...

Wzut

ich habe aber keine Ahnung welche IDs deine CULS haben ob die selbstgebaut sind oder von Busware gekauft, welch eFW Version du benutzt  und wie du die beiden optisch auseinander hälst, alles was du bisher dazu verraten hast war :
Zitat
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
und da sieht man leider nicht wer wer ist ...
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

Hallo,

da geb ich dir natürlich recht.
Das war das erste CFG-File... in der Zwischenzeit habe ich auf Anraten von einem Forenbetreiber auf Select-by-id umgestellt... und jetzt steht dort:

Auszug aus der Device-Anzeige in FHEM vom CUL:
DEF
/dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134
(...)
VERSION
V 1.67 CUL868


Und... ich kann die CUL mit einem Schalter an und ausschalten. Sprich alles andere ausser dem CUL868 ist aktuell gar nicht an! Nachdem ich alle anderen ausgeschaltet habe, habe ich den Raspi neu gestartet. So sollte eigentlich physisch genau einer verfügbar sein und genau dieser wird mit der ID vom Raspi erkannt. Diese hab ich in der CFG eingebunden und darüber empfange und (hoffentlich bald sende ich auch darüber wieder) ich Messages.

Firmware hab ich letztlich noch extra geflashed. Sollte eigentlich die aktuellste sein, die ich gefunden habe. (http://culfw.de/culfw.html).

Reicht dir das als Information?

================
Aktueller Stand der Not enough-Message-Meldungen.

2017.10.23 23:47:36 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 113. Waiting 106 seconds. Currently 90 messages are waiting to be sent.
2017.10.23 23:49:30 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 9, but we need 113. Waiting 104 seconds. Currently 90 messages are waiting to be sent.

Seit gestern :-(

Wzut

Ok, dann ist das klar. Ein echter CUL und keine Bastellösung.
Deine V1.67 ist ja recht neu, hattest du die schon drauf als die Probleme anfingen oder damals noch etwas Älteres ?
Meine ist mit V1.60 da etwas älter wird aber auch so bleiben (never change  a .... )
Tja was bleibt ? Im Marktplatz mal nach einem billig 868CUL schauen und den testen ? den wenn dein CUL wirklich einen Hardware Schaden hat wirst du das mittels Software nicht ausbügeln können.


Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

Die Firmware war nicht ganz so alt... war aber neuer als deine.
Genaue Bezeichnung wusste ich nicht.
Mir hat jemand empfohlen die upzugraden, da die Probleme vorher auch waren.

Und jetzt scheinen sie ja auch wieder zu kommen... also liegt es auch nicht an der Firmware.

Dann bestell ich mir wohl mal nen neuen bei Busware :-( Schade, aber was soll man machen.
eine weitere richtige Idee hast du auch nicht mehr, oder? Les ich da zumindest raus :-(

Wzut

Richtig ich bin auch ohne weitere Ideen, allerdings würde ich zum testen im Marktplatz nach einem billigen Selbstbau nanoCUL schauen :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

Hallo. so ich habe mir jetzt mal einen neuen CUL bestellt.
und habe nach einem Neustart das gleiche Problem wie zuvor... Sprich, das Problem liegt nun mal nicht am CUL würde ich jetzt unterstellen sondern eher an FHEM.

Empfangen tun die beiden CUL ja trotzdem ohne Probleme...
also muss irgendwo die Sende-Funktion ein Problem erzeugen.

Folgende Feststellungen:


  • CUL-Firmware 1.67 (aktuellste)
  • FHEM aktuell / aktualisiert
  • FHEM / CUL Empfang anscheinend Problemlos
  • FHEM / CUL Versand von Messages führt nach kurzer Zeit zur Meldung "not enough Credits Messages"
  • Gleiches Phänomen bei CUL1 und CUL2 (neu) - sprich ein Defekt an der Hardware ist eher unwahrscheinlich
  • FHEM.cfg kann gerne eingesehen werden - da sind nur die Defines der Devices drin sowie aktuell auch die, die ignore(d) werden sollen (z.B. vom Nachbarn die eigenen (z.B.))
  • Vermutung: Irgendwo in FHEM werden Messages "gespeichert", die nicht versandt werden konnten und werden nach den Neustart wieder rausgeholt und erneut versandt (sogar 3x, da kurze Zeit hintereinander ein Versand stattfindet, obwohl ich nur 1 (!) Message an ein Device abgegeben habe. Das führt erneut zum Problem... Credits-Verbrauch für den Versand zu einem Device, was es nicht annimmt. Also wieder die Meldung.
  • In der Config kann man sich den CUL-Buffer anzeigen lassen. get myCUL raw T02 - Quelle: https://wiki.fhem.de/wiki/CUL
    Ich hoffe, dass ist das was ich auch denke - nämlich der Buffer, wo die zu verschickenden Messages drin stehen. Der ist leer! Auch nach einem Neustart, was ja eigentlich richtig sein sollte - wenn meine Vermutung richtig ist.
  • Bei den Einstellungen RAW X61 wird NICHTS anderes angezeigt. Das soll doch detailiert anzeigen, was in der Meldung drin ist. - Quelle: https://wiki.fhem.de/wiki/CUL
  • Evtl. gibt es in FHEM noch andere Stellen, wo die Messages gebuffert werden für einen späteren Versand... aber das hab ich nicht rausbekommen... und somit kann ich das auch nicht testen
  • Eigentlich könnte ich wieder die alte Config aktivieren (aktuell ist ja nur die Test-Config drin)... es scheint ja das Problem genereller Natur in FHEM zu liegen. So kann ich wenigstens den Rest wieder nutzen :-)

Wäre schon schön, wenn wir das Problem weiter eingrenzen könnten und weiter suchen würden... denn irgendwo ist ja ein Fehler drin. Da alles auf Anfang stand... und die Hardware neu ist, kann ja jetzt eigentlich nur die Software ein Problem darstellen, oder? Evtl. habt ihr ja noch andere Tipps.

Beta-User

Kann es sein, dass die Baudrate falsch ist?
Da hat sich irgendwann was geändert, versuch's mal mit 38400 (?)

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

walterschmitz

#28
ist das Part beim DEF... hinter dem @
Bei mir steht da ja grad:
/dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134

Da müsste an statt von 9600 dann die 38400 rein?

Mal ne Frage dazu?
- Warum kann ich dann denn trotzdem empfangen?
- wenn das geändert wurde... würde das dann nicht automatisch bei nem Update entsprechend angepasst?

Danke für den Hinweis... ist ja schnell umzusetzen und auszuprobieren !!!


Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files