Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit of 500 states if no options.count is defined #74

Closed
paul53 opened this issue Jul 22, 2020 · 10 comments
Closed

Limit of 500 states if no options.count is defined #74

paul53 opened this issue Jul 22, 2020 · 10 comments

Comments

@paul53
Copy link
Contributor

paul53 commented Jul 22, 2020

Werden nur die Optionen start, end und aggregate: 'none' angegeben, erfolgt eine Begrenzung der Anzahl der Zustände bei "getHistory" auf 500.

Siehe Forum

Versions:

  • Adapter version: 1.9.3
  • JS-Controller version: 3.1.4
  • Node version: 12.18.0
  • Operating system: Ubuntu 18.04

Das gleiche trifft auf den SQL-Adapter zu.

@paul53 paul53 changed the title Limit of 500 states if no option.count is defined Limit of 500 states if no options.count is defined Jul 22, 2020
@paul53
Copy link
Contributor Author

paul53 commented Jul 22, 2020

Hinweis: aggregate.js: Zeilen 414, 449

@Apollon77
Copy link
Contributor

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

@Hans-Zwiesel
Copy link

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
Copy link
Contributor

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
Copy link

Hans-Zwiesel commented Jul 23, 2020

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor Author

paul53 commented Jul 24, 2020

@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
Copy link

@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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants