Not enough Credits-Problem

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

Vorheriges Thema - Nächstes Thema

walterschmitz

Hallo zusammen,

ich habe aktuell in der Log folgende Einträge vermehrt:
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
Currently 87 messages
Da 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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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:
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:

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!

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

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

Hat 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).

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 :-(
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.


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

Zitat von: walterschmitz am 23 September 2017, 22:50:29
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

Zitatzwei 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!

Zitat2017.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 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 ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

CUL868 version => V 1.63.01 CUL868 (F-Band: 868MHz)
Meinst du diese Ausgabe, die ich bekommen, wenn ich beim CUL868  das 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 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.

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 NEQ1016748

gestern 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 2017.10.06 00:53:26 2: CUL_MAX_SendQueueHandler: Missing ack from 16d037 for 0fd0040312345616d03700110600b597
Verstehen, 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...
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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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 :)
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

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

walterschmitz

Umgehend nach dem Neustart... mit 38400 Baud...

Habe ich ein Befehl über FHEM an ein Device abgegeben... und erhalte wenige Minuten später
2017.10.29 08:54:40 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 74, but we need 113. Waiting 39 seconds. Currently 1 messages are waiting to be sent.
2017.10.29 08:55:26 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 113. Waiting 106 seconds. Currently 4 messages are waiting to be sent.


Zufall oder was denkst du?
Ich melde mich heute Nachmittag oder Abend noch mal, ob es evtl. besser wird.

Beta-User

Klappt geht ccconf?


Wenn ja: warten, ansonsten zurück und ccconf mit @9600
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

versteh nicht was du meinst:

bei CCCconf bekomme ich was zurück:
CUL868 ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB

also warten, oder?

Beta-User

Wenn eine vernünftige Antwort kommt, stimmt die baud-rate. Also erst mal warten....
Kannst ja mit dem anderen CUL mal testen, ob auch @9600 eine Antwort kommt.
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

Beta-User

So, mit einer vernünftigen Tastatur etwas ausführlicher:

Scheinbar wurde die Baud-Rate beim CUL irgendwann geändert auf 38400, ohne dass das irgendwo groß dokumentiert zu sein scheint (nur in der FHEM-Commandref zu CUL finden sich die 38400, ich hatte aber neulich den Fall, dass jemand die 38400 eingestellt hatte, und ich entsprechend commandref bei culfw.de der Ansicht war, das müßte falsch sein, zumal mit firmware 1.61 @9600 noch richtig war/ist)...

Wie dem auch sei: Wenn vom CUL eine sinnvolle Antwort zurückkommt, ist die Baudate ok, die falsche Baudrate macht das ganze zu einem unverständlichen Datenkauderwelsch, der aber ggf. trotzdem interpretiert wird. Die ccconf-Abfrage ist dazu eine Art Test.

Dann: wenn Du zwei CUL nutzt, und das beides 868-er sind, haben die die gleiche USB-Kennung, was wieder zu Problemen führen kann. wenn die Ausgabe von ls -l /dev/serial/by-id bis auf den angezeigten link auf das ACM-Device identisch ist, solltest Du entweder eine firmware nochmal selber bauen (der USB-Name steht irgendwo im Quellcode,  dort wäre die ID zu ändern), oder beide dann "by-path" einbinden.

Ich würde - bei identischem by-id-Namen - also vorläufig erst mal einen abstöpseln und den anderen für FHEM löschen.

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

Hallo,

CCCconf hat bei mir ja was zurückgegeben. Und ich habe aktuell auch NUR den neuen dran. Und die Baudrate habe ich auch schon auf 38400 geändert.
Soweit erst mal das?

Trotzdem kam das :-(

Ich könnte zum Vergleich den zweiten (alten) CUL gerne mal zusätzlich aktivieren und schauen, ob es Unterschiede gibt... dann ist aber die Fehlersuche noch schwieriger, oder?

Das mit den beiden CUL und der gleichen ID versteh ich grad nicht. Ich habe ja nur einen drin.
Das was du meinst, wäre nur dann der Fall, wenn BEIDE gleichzeitig eingebaut wären, oder? Aktuell sind die ausgetauscht! und da verwundert mich das nicht, dass die by-id-Links gleich aussehen.
Ich würde eher davon ausgehen, dass wenn ich BEIDE drin hätte, ich 2 by-id-links erhalten würde... um sie irgendwie zu unterscheiden. Aber ausprobiert hab ich das noch nicht. Könnte ich aber gern, wenn das hilfreich wäre.

Eine Firmware selbst gebaut habe ich übrigens noch nicht. Ich habe die aktuelle von von culfw.de geholt und unter Windows via Flip 3.4.7 installiert (Installiert / geflashed habe ich die CUL-FW_1.67\culfw-1.67\Devices\CUL\CUL_V3.hex aus dem File 1.67). Da ich sowas noch nie gemacht habe, versteh ich natürlich auch nicht, was du meinst mit USB-Name steht irgendwo im Quelltext :-) Aber soweit sind wir ja auch noch nicht.


Beta-User

Sorry, ich wollte dich nicht verwirren.

Nur ein CUL angestöpselt ist gut, und am flashen scheint es auch nicht zu liegen, daher: an der Stelle
ist erst mal keine Aktion erforderlich.

Habe jetzt auch mal meinen CUL auf @38400 umgestellt, weil ich wissen wollte, ob da was zurückkommt. Ergebnis: ich bekomme bei beiden Datenraten eine Antwort auf get ccconf....
Soweit ich mich jetzt nach etwas Rätseln erinnere war es so, dass ein Modem (=ACM-Gerät) die Datenrate wohl auf Anforderung umstellen können muß. Damit dürfte also beides gehen...

ABER: Die Antwort auf get ccconf war eine andere: @38400 habe ich eine bwith von 325KHz zurückgemeldet erhalten, auf @9600 waren es erst nur etwas mehr als 100 (wie bei dir unten).

Setz mal bitte ein "raw e" ab, damit wird der CUL in den Werkszustand zurückgesetzt. Vielleicht war schlicht die Empfindlichkeit so verstellt, dass nicht mehr alle Geräte innerhalb des Frequenzbands lagen.

Ansonsten ist es wirklich irgendwas MAX-Spezifisches, da kann ich dann auch nicht weiterhelfen.

Das mit den Änderungen im Quellcode ist nur dann relevant, wenn beide CUL an derselben Maschine genutzt werden sollen, aber damit solltest du dich erst mal nicht belasten.

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

Hallo,

ich hab mal Set Raw e gemacht.
Danach warte ich mal ab. Und um die Uhrzeit zu markieren hab ich mal ein Shutdown restart gemacht... Dann hab ich es in der Log-File gleich leichter mit suchen :-P

So... die Meldung danach war:
2017.10.29 15:52:58 0: Server shutdown
2017.10.29 15:53:00 1: Including fhem.cfg
2017.10.29 15:53:00 3: telnetPort: port 7072 opened
2017.10.29 15:53:01 3: WEB: port 8083 opened
2017.10.29 15:53:01 3: WEBphone: port 8084 opened
2017.10.29 15:53:01 3: WEBtablet: port 8085 opened
2017.10.29 15:53:01 2: eventTypes: loaded 374 events from ./log/eventTypes.txt
2017.10.29 15:53:01 3: Opening CUL868 device /dev/serial/by-id/usb-busware.de_CUL868-if00
2017.10.29 15:53:01 3: Setting CUL868 serial parameters to 38400,8,N,1
2017.10.29 15:53:01 3: CUL868: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2017.10.29 15:53:01 3: CUL868 device opened
2017.10.29 15:53:01 2: Switched CUL868 rfmode to MAX
2017.10.29 15:53:01 3: CUL_MAX_Check: Detected firmware version 167 of the CUL-compatible IODev
2017.10.29 15:53:02 1: Including ./log/fhem.save
2017.10.29 15:53:02 1: usb create starting
2017.10.29 15:53:02 3: Probing CUL device /dev/ttyAMA0
2017.10.29 15:53:02 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.10.29 15:53:02 3: Probing ZWDongle device /dev/ttyAMA0
2017.10.29 15:53:03 3: Probing FRM device /dev/ttyAMA0
2017.10.29 15:53:08 1: usb create end
2017.10.29 15:53:08 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.10.29 15:53:08 0: Featurelevel: 5.8
2017.10.29 15:53:08 0: Server started with 40 defined entities (fhem.pl:15294/2017-10-20 perl:5.024001 os:linux user:fhem pid:26543)
2017.10.29 15:53:22 3: CUL868: Unknown code Z020208, help me!
2017.10.29 15:53:28 3: CUL868: Unknown code Z0118, help me!
2017.10.29 15:53:30 2: CUL_MAX_SendQueueHandler: Missing ack from 08d15f for 0f00040312345608d15f00111d0fb59b
2017.10.29 15:53:30 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 52, but we need 113. Waiting 61 seconds. Currently 2 messages are waiting to be sent.


Die beiden Unkown Codes werden jetzt angezeigt... und direkt ein Missing Ack sowie die beiden - eigentlich dürften sie ja gar nicht existieren - Messages, die gerade nicht verschickt werden konnte.

Aber warten wir mal ab und harren der Dinge, die gleich kommen.
Danke erst mal.

walterschmitz

Ich habe jetzt mal FHEM deinstalliert (apt-get remove und purge und autoremove) damit alles weg ist.

Und anschließend nach der FHEM-Wiki Seite wieder installiert über die Nightly-Debian-Variante.

Und auf eine ganz blanke FHEM-Installation mit Autocreate... alle Devices werden nach einiger Zeit wieder gefunden... kann ich IMMER NOCH nicht einen Befehl an ein Device absetzen.

Ich erhalte umgehend wieder die Meldung
2017.11.08 23:25:07 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 107, but we need 110. Waiting 3 seconds. Currently 1 messages are waiting to be sent.
2017.11.08 23:25:17 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 110. Waiting 103 seconds. Currently 1 messages are waiting to be sent.


Was ist denn hier für mich echt noch machbar...
Neuer CUL868 --> keine Änderung
Neues FHEM --> keine Änderung
keine Veränderungen am Quellcode irgendwelcher Files
keine Device verändert (funktioniert ohne FHEM problemlos zwischen den gepairten Devices)
keine handgebauten Devices oder CULs

Ich bin echt ratlos, was ich machen könnte, bzw. was hier gerade falsch läuft.

walterschmitz

#39
und ich schon wieder... mal beim CUL_MAX das verbose auf 5 gestellt...

jetzt erhalte ich so ne Meldung im Log:
CUL_MAX_Send: enqueuing 0b02004012345616d5430063
123456 ist die Def, die beim CUL_MAX durch den Autocreate eingetragen wurde
16d543 ist die ID des Device

der Rest drum rum, sagt mir noch nichts.
Ist auf jeden Fall das Device, welches ich einen Testbefehl gegeben habe.

Auf jeden Fall habe ich jetzt rausgefunden, was meine Credtis verbraucht (denke ich):
2017.11.09 00:44:33 5: CUL_MAX_BroadcastTime: payload 110900ace1
2017.11.09 00:44:33 5: Broadcast time to 0e1d4f
2017.11.09 00:44:33 5: CUL_MAX_Send: enqueuing 0f0404031234560e1d4f00110900ace1
2017.11.09 00:44:33 5: CUL_MAX_SendQueueHandler: 1 items in queue
2017.11.09 00:44:33 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 143
2017.11.09 00:44:33 5: Updating TimeInformation payload
2017.11.09 00:44:34 5: CUL_MAX_SendQueueHandler: 1 items in queue
2017.11.09 00:44:34 5: CUL_MAX_SendQueueHandler: 1 items in queue
2017.11.09 00:44:35 5: CUL_MAX_SendQueueHandler: 1 items in queue
2017.11.09 00:44:35 5: CUL_MAX_SendQueueHandler: 1 items in queue
2017.11.09 00:44:36 5: CUL_MAX_SendQueueHandler: 1 items in queue
2017.11.09 00:44:36 5: CUL_MAX_SendQueueHandler: 1 items in queue
2017.11.09 00:44:36 5: CUL_MAX_SendQueueHandler: Retry 0e1d4f for 0f0404031234560e1d4f00110900ace1 count: 3
2017.11.09 00:44:39 5: CUL_MAX_SendQueueHandler: 1 items in queue
2017.11.09 00:44:39 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 36
2017.11.09 00:44:39 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 36, but we need 113. Waiting 77 seconds. Currently 1 messages are waiting to be sent.

Das ist immer in regelmässigen / unregelmässigen Abständen das Broadcast time an bestimmte Devices. Und hierbei entsteht ein Versand, der nicht beantwortet wird bzw. der zu einem Fehler führt.
Bei einigen Devices führt das dazu, dass die Queue voller und voller wird.
Das sind alles meine Devices, die durch den AutoCreate erstellt wurden... an denen ich noch keine Veränderungen vorgenommen habe... also alles blankes FHEM (bis auf das Verbose 5 beim CULMAX)

aber das ist jetzt so tief im Quellcode / FHEM enthalten... da geh ich momentan nicht ohne Tipps von Cracks ran :-)

walterschmitz

so... nächste Vermutung, es sind wieder 365 Messages in der Pipeline :-(

Ich gehe davon aus, dass FHEM regulär arbeitet... dann in x-beliebigen Zeitabschnitten was an die Devices schicken möchte, und das nicht angenommen wird, weil die Verbindung zwischen Device und CUL nicht sauber ist.

WIE KANN ICH NACHTRÄGLICH Device, die mal mit dem CUL gepaired waren, wieder trennen und repairen bzw. ich würde dem CULMAX mal ein anderes DEF (nicht 123456 von der Autocreate vergeben) geben sondern dies abändern. Anschließend würde ich gerne jeden Tag zwei Device (WT und HT) zurücksetzen und repairen, die jeweils ohen FHEM pairen und anschließend in FHEM associaten.

Wie sollte ich hier vorgehen. ich gehe eher davon aus, dass ich jetzt die Geräte alle auf Werkseinstellung zurücksetzen müsste?

Andere Vorschläge?

Muss an den Devices mal später die Firmware upgegradet werden? Nur so als Idee? Wenn ja, wie macht man das via FHEM? Dann würde wirklich jede Firmware aktuell sein (CUL, DEVICEs und FHEM wird sowieso immer updated)

zweiundzwanzig

Hi,
ich kenne Probleme mit nicht richtig gepairten Devices. Bei mir trat das immer auf wenn ich zu ungeduldig war und wärend dem Pairen die credits alle wurden.
Ohne jetzt jedes Detail deiner Probleme nachvollzogen zu haben würde ich, wenn das Device schon in deiner Config mit ID vorhanden ist, vorschlagen:

1. autocreate abschalten

2. Sicherstellen, dass genug credits vorhanden sind (man braucht zum Pairen eine Menge davon weil die Wochenprogramme übertragen werden)

3. Device am Device selber resetten (Werkseinstellung) und dann einfach neu pairen. Dem CUL_MAX ist das komplett egal.

Vielleicht löst das die Probleme ja schon?
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

walterschmitz

so.... ganz langsam und mit Bedacht nehm ich jeden Tag ein WT vom Netz und resette es. Dann repaire ich es mit dem CUL und FHEM.
Später mach ich die HT und FK fertig... und dann werde ich Tag für Tag immer wieder ein Gerät mit den jeweils anderen pairen, damit alles funktioniert, wenn bei FHEM mal wieder (hoffentlich nie) so ein Crash bzw. Ausfall passiert.

Um das aber zeitnah zu benachrichtigen würde ich mir wünschen, dass ich über diese Not Enough Credits-Meldungen ein Notify erstellen könnte.

Ich habe aktuell aus dem EventMonitor raus KEINE Möglichkeit daraus ein Event zu machen.
Kann mir jemand erklären, wie ich das hinbekommen könnte bzw. würde jemand eine FHEM Erweiterung programmieren, die bei Credits-Problemen eine Benachrichtigung rausschickt (per Email oder Pushbenachrichtigung).

Dann hätte ich damals umgehend reagieren können... so ist es erst nach langem Abwarten aufgefallen, wo das Problem lag.


zweiundzwanzig

Mailversand geht so: https://wiki.fhem.de/wiki/E-Mail_senden#Raspberry_Pi

Mein Notify dafür sah ungefähr so aus allerdings passiert das bei 900 credits zu oft! :

defmod N_credits_Email notify .*CUBe_.*:credit10ms:.* { if (($EVTPART1 < 100)&& (time gt $main::NewMailtimeCredits)) {# Variable NewMailtime ist in 99_myutils definiert!\
  { SendeMail('bla@googlemail.com', 'FHEM Credits Warnung!', $NAME.': '.$EVENT)};; \
   Log 3, "$NAME : CUBE-Warnung $EVTPART1";; \
   $main::NewMailtimeCredits = time + 14400;; #4 Stunden bis zur nächsten Mail\
  } \
}
attr N_credits_Email room CUN,Hausmeister
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

walterschmitz

würde das auch ohne CUBE funktionieren und nur mit einem CUL?

Dann müsste doch der reguläre Ausdruck ein anderer sein, oder?

Ansonsten müssten / könnte der Rest fast gleich bleiben?
Danke für die Vorlage des EmailNotify.

zweiundzwanzig

Na klar, mein CUL-DEVICE hat halt den Namen "Cube". Wenn du alles entsprechend ersetzt wird das klappen. Aber es kommen dann halt schnell sehr viele Emails. :-)
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden