Limit of 500 states if no options.count is defined about iobroker.history

[paul53]

Hinweis: aggregate.js: Zeilen 414, 449

[Apollon77]

Ja, und? ;-). Alles zurückzugeben ist keine echte Option weil dann RAM und io explodiert. Oder soll es nur dokumentiert werden?

[Hans-Zwiesel]

Es sollte zumindest ein Fehler ausgelöst werden wenn so eine Funktion auf Anschlag ist und
Anwender dann ohne Warnung mit falschen Daten weiterarbeiten.

[Apollon77]

Was meinst Du? Wegen RAM? Das kann der Adapter wirklich nicht erkennen ... Du musst bei deinem System sicherstellen das Du für das was Du tust genug Reserven hast (ist ja nicht nur RAM ... ist ja auch IO auf der SD Karte oder oder oder

[Hans-Zwiesel]

Ich habe die Begrenzung auf 500 Datensätze als Anschlag gemeint, das ist ja offensichtlich so programmiert.
RAM und IO hätte ich noch genügend.

Übrigens ist mir aufgefallen, als ich einigemale das Script laufen ließ (das mit getHistory), dass meine MQTT-Client Überwachung auf allen Clients ausgelöst hatte (bei den Clients kam der MQTT HeartBeat nicht mehr an) und danach hatte ich wieder so einen MQTT Eintrag bei den Objekten, der nicht gelöscht werden kann.
Damit sind ja schon viele Anwender geplagt.
Ich kann aber nicht sicherstellen, dass das ursächlich war, ist aber zeitlich schon auffällig, weil sonst wirklich nichts ungewöhnliches vorgekommen ist.

[Apollon77]

Die Begrenzung ist nur zum selbstschutz der Anwender da wenn Sie die Abfrage "falsch bedienen". Jeder der einen count Wert übergibt weiss hoffentlich was er tut.

Zu dem anderen eiss ich nicht was genau du mit einem "MQTT eintrag der nicht gelöscht werden kann" meisnst - wäre aber denke eher ein MQTT issue. Was passiert wenn du mehrere gethistory Anfragen parallel schickst ist das jede davon selbst die Daten raussucht. Das frisst CPU und IO (bei history weilalles aus den Files gekratzt wird). Warum dann MQTT (also Netzwerk) Probleme macht liegt ggf an der Hardware oder Last oder RM (und damit Swapping) oder sowas-. Müsste man exakt mit einem "top" mal checken wenn man sowas macht

[Hans-Zwiesel]

Also, mir hat die Abfrage der paul53 geschickt und ich meine, der kennt sich schon aus. Wenn der schon die Abfrage "falsch bedient", was machen dann normale User?
Woher soll ein User wissen, wieviele Treffer die Abfrage bringt?

Wegen der MQTT Einträge, die nicht gelöscht werden können:
Wie geschrieben, ist mir nur der zeitliche Zusammenhang aufgefallen.
z.B.: https://forum.iobroker.net/topic/16193/kann-im-mqtt-objekte-nicht-l%C3%B6schen ff.

Ich würde ja diese gethistory Abfrage entfernen, wenn kein stabile und sichere Vorgehensweise möglich ist.
Eine kleine Anekdote aus früheren Tagen:
In unserem Betrieb hat einmal ein Jung-Programmierer den Auftrag erhalten, eine bestehende Kundenverwaltung von
8-Bit TurboDOS Multiuser auf 16Bit MSDOS Netzwerk mit mySQL Datenbank Server zu bringen.
Dabei hat er einen Kunden mit Select * from all gesucht.
Mit seinen 10 Testkunden ist das ja nicht aufgefallen. Aber als dann der echte Kundenstamm mit 250000 Einträgen
scharf war, dann hat er sich gewundert, wieso diese alten 8-Bit Systeme nur 0,1 Sec. benötigen um einen Kunden zu finden
und die neuen 16-Bit über mySQL 5 Minuten.
Ich werde das nie vergessen und hoffe, Du weist was ich meine.

[paul53]

@Hans-Zwiesel: Wenn etwas nicht dokumentiert ist, halten sich auch meine Kenntnisse in Grenzen. Erst nachdem die Begrenzung auf 500 Zustände aufgefallen ist, habe ich in den Quell-Code geschaut.

[Hans-Zwiesel]

@paul53: Mir ist die Begrenzung auch aufgefallen, danach habe ich diese Funktion verbannt und auf SQL Abfrage umgestellt.
Für den Quell-Code reichen meine Kenntnisse leider nicht. Möglicherweise weiß ich oft nicht was ich tue. :-)

[Apollon77]

Ich würde ja diese gethistory Abfrage entfernen, wenn kein stabile und sichere Vorgehensweise möglich ist.

Ich verstehe das Problem noch nicht. Es ist ein Default eingebaut wenn ein Parameter nicht angegeben ist. Das ist normal weil "unlimitiert" nie eine gute Idee ist. Ich habe die Readme aktualisiert