UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[apollon77]

Hey,

ich habe ein neues Feature in SQL und InfluxDB eingebaut und Sie sind vorab auf Github verfügbar: Man kann jetzt beim Konfigurieren der einzelnen Datenpunkte angeben in welchem Datentyp die Speicherung passieren soll. Normalerweise versuchen die Adapter beim Speichern Automatisch den Datentyp zu erkennen. Das klappt auch super so lange die Daten dann immer in diesem Datentyp vorliegen. Sobald aber z.B. mal ne Zahl und mal eine Zeichenkette drinsteht passieren komische Dinge.

Daher kann man jetzt für solche Datenpunkte den Datentyp definieren, wenn man es braucht. Der Standard ist "Auto" (also wie bisher auch).

Sobald ein Datenpunkt angelegt ist sollte der Typ aber nicht mehr geändert werden. Ich muss da nochmal überlegen wie man das besser darstellt.

Ideen gern

Am Ende sollte sich beim Update von Github installieren nichts ändern und alles weiter so klappen wie bisher auch. Das ist das wichtigste. Falls jemand von Euch mit dem neuen Feature spielen will dann auch gern

Danke!

Ingo F

[Thisoft]

Habe gerade SQL 1.5.0 installiert. Jetzt hagelt es Fehlermeldungen in der folgenden Form:

sql.0
2017-03-03 12:39:14.209
info
Datatype javascript.0.Heizung.T2: Currently: number, StorageType: false
sql.0
2017-03-03 12:39:14.206
info
Datatype javascript.0.Heizung.T1: Currently: number, StorageType: false
sql.0
2017-03-03 12:39:14.177
info
Datatype javascript.0.Heizung.T0: Currently: number, StorageType: false

Was soll denn "StorageType: false" aussagen? Der Datentyp in der Db ist definitiv auch number! Das Konfigurationsfenster zu den einzelnen DP's öffnet sich auch gar nicht erst

Ich gehe jetzt erstmal auf die letzte Version zurück

[apollon77]

@Thisoft:

Habe gerade SQL 1.5.0 installiert. Jetzt hagelt es Fehlermeldungen in der folgenden Form: `

Sind keine Fehler nur Infos Hab ich vergessen auf debug zu stellen :-)) Wird geändert.

@Thisoft:

Was soll denn "StorageType: false" aussagen? Der Datentyp in der Db ist definitiv auch number! `
Das sagt an der Stelle das kein expliziter Typ für diesen Datenpunkt eingestellt wurde, damit "Automatische Behandlung wie bisher auch". Also alles gut

@Thisoft:

Das Konfigurationsfenster zu den einzelnen DP's öffnet sich auch gar nicht erst `

Muss ich mir ansehen heute Abend Hattest Du "iobroker upload sql" gemacht?

[Thisoft]

Sorry, "iobroker upload sql" hatte ich vergessen. Jetzt geht das Fenster zumindest auf. Allerdings bleibt es weitgehend leer - und das in Version 1.4.6, was is denn das nu wieder?

[apollon77]

ist das bei allen Datenpunkten so?

Starte iobroker mal komplett neu … und versuch ggf mal Browser cache und so zu leeren ... aber hab ich noch nie gesehn. Teste es heute Abend!

[Thisoft]

Ja, es war bei allen Datenpunkten so…

iobroker hatte ich schon mehrmals neu gestartet, Browsercache leeren etc. hat auch nix gebracht.

Was geholfen hat war ein Neustart des Rechners auf dem ich den Browser mit dem ioBroker-Admin offen hatte! Was sich da auch immer "verschluckt" hatte...

[apollon77]

Fehler in Edit-Maske gefunden und auf github gefixt. Das Logging sollte auch weniger sein …

Bitte nochmals versuchen

[Thisoft]

So, hab die neue Version seit gestern Abend laufen. Sieht soweit gut aus, keine Fehlermeldungen und kein exzessives Logging

Allerdings finde ich nirgends die (neue) Möglichkeit den Datentyp der zu loggenden DP's einzustellen. Der Konfig-Dialog sieht aus wie immer… Und dabei habe ich das jetzt wirklich auf verschiedenen Rechnern mit verschiedenen Browsern getestet. Und "iobroker upload SQL" hab ich diesmal auch gemacht . Aber warten wir mal ab, diese Browser-Caches sind sowieso nicht meine Freunde :roll: vielleicht überlegen die sich irgendwann doch noch, die neuen Einstellungen zu laden...

[apollon77]

Die Einstellung für den Datentyp ist nur in dem Datenpunkt-Dialog (im generellen Instanz-Dialog ist nichts drin weil es dafür keinen Sinn macht).

sollte so aussehen:

[apollon77]

Es wurde auf Request in http://forum.iobroker.net/viewtopic.php?p=57214#p57214 noch die ARbeitsweise von "Debounce" geändert auf etwas was dem Namen gerecht wird

Bisher: Es wurden so lange wie in Debounce-Time angegeben keine weiteren Änderungen geloggt. Bedeutet aber das potentiell nicht der aktuellste Wert auch als letztes geloggt wurde. Damit Statistiken pot. falsch.

Ab den neuen Versionen: Wenn während der Debounce-Zeit eine weitere Änderung der Daten kommt, dann wird der letzte Wert nicht geloggt und die Debounce-Zeit für den neuen Wert neu gestartet. Damit ist sichergestellt das ein "stabiler Wert" (der sich in der Debounce-Zeit nicht nochmals geändert hat) in jeder Fall geloggt wird und damit der aktuellste Wert da ist. Es "fehlen" pot. Werte die dazwischen waren, aber das war vorher auch so. Es kann jetzt aber passieren, dass bei falschen Debounce-Einstellungen nichts mehr geloggt wird weil die Werte schneller kommen als die Debounce-Einstellung und damit nie stabil sind. Das muss ggf geprüft werden.

Bitte Versionen vom Github testen!

[Pman]

Zum Thema Datentypen: Ich hatte (mit der alten Version) den Fall, dass ein Datenpunkt zu Beginn schon falsch angelegt wurde, da der erste Wert nach anlegen der History-Einstellungen nicht dem korrekten Typ entsprach (String statt Bool). Dadurch war der Typ schon falsch in der Datenbank und ich musste ihn schlussendlich manuell aus der Datenbank entfernen. Ich glaube, dass auch jetzt mit deiner Version dieses Problem nicht behoben wäre, da du sagst, dass dieses Einstellung nur einmalig getätigt werden kann. Ich würde demnach vorschlagen, dass man einen ENTFERNEN Button hinzufügt, mit dem man den Datenpunkt wieder komplett aus der Datenbank raus bekommt, inkl. allen Werten. Natürlich müsste da noch ein Bestätigungsdialog auftauchen, damit man nicht aus Versehen löscht.

@apollon77:

Es "fehlen" pot. Werte die dazwischen waren, aber das war vorher auch so. Es kann jetzt aber passieren, dass bei falschen Debounce-Einstellungen nichts mehr geloggt wird weil die Werte schneller kommen als die Debounce-Einstellung und damit nie stabil sind. Das muss ggf geprüft werden. `
Dass manche Werte nicht geloggt werden ist ja irgendwie auch Sinn der Sache. Wenn gar nicht mehr geloggt wird, weil die Werte dauerhaft zu schnell kommen, sollte man die Debounce-Zeit verringern, das ist dann eher ein Konfigurationsfehler finde ich. Der Standardwert sollte evtl. eher 0 (aus) oder ein geringer Wert wie 100ms sein, damit bei nicht-Beachtung dieser Einstellung weniger schief gehen kann.

Eine Anmerkung/Frage hätte ich noch: wird der Wert eigentlich mit dem ursprünglichen Timestamp gespeichert oder mit dem Zeitpunkt wenn er denn endgültig gespeichert wird?

[apollon77]

@Pman:

Zum Thema Datentypen: Ich hatte (mit der alten Version) den Fall, dass ein Datenpunkt zu Beginn schon falsch angelegt wurde, da der erste Wert nach anlegen der History-Einstellungen nicht dem korrekten Typ entsprach (String statt Bool). Dadurch war der Typ schon falsch in der Datenbank und ich musste ihn schlussendlich manuell aus der Datenbank entfernen. Ich glaube, dass auch jetzt mit deiner Version dieses Problem nicht behoben wäre, da du sagst, dass dieses Einstellung nur einmalig getätigt werden kann. Ich würde demnach vorschlagen, dass man einen ENTFERNEN Button hinzufügt, mit dem man den Datenpunkt wieder komplett aus der Datenbank raus bekommt, inkl. allen Werten. Natürlich müsste da noch ein Bestätigungsdialog auftauchen, damit man nicht aus Versehen löscht. `
Habe es als Feature-Request ins Trello gepackt.
@Pman:

@apollon77:

Es "fehlen" pot. Werte die dazwischen waren, aber das war vorher auch so. Es kann jetzt aber passieren, dass bei falschen Debounce-Einstellungen nichts mehr geloggt wird weil die Werte schneller kommen als die Debounce-Einstellung und damit nie stabil sind. Das muss ggf geprüft werden. Dass manche Werte nicht geloggt werden ist ja irgendwie auch Sinn der Sache. Wenn gar nicht mehr geloggt wird, weil die Werte dauerhaft zu schnell kommen, sollte man die Debounce-Zeit verringern, das ist dann eher ein Konfigurationsfehler finde ich. Der Standardwert sollte evtl. eher 0 (aus) oder ein geringer Wert wie 100ms sein, damit bei nicht-Beachtung dieser Einstellung weniger schief gehen kann.
Der aktuelle Default-Wert für Debounce sind 10 Sekunden. Zu viel? 1s wäre vllt besser?

@Pman:

Eine Anmerkung/Frage hätte ich noch: wird der Wert eigentlich mit dem ursprünglichen Timestamp gespeichert oder mit dem Zeitpunkt wenn er denn endgültig gespeichert wird? `
Es ist immer der eigentliche Timestamp. Nur das schreiben an sich ist verzögert. An den Daten wird da nichts geändert.

[Pman]

Die Frage ist: Was ist ein guter default-Wert für Leute, die nichts an dem Wert verändern und erwarten, dass es einfach funktioniert, also loggt.

Zu kleiner Wert:

Bei Datenpunkten mit starkem "flimmern" wird der Historyadapter überlastet und es werden sehr schnell große Datenmengen geloggt.

Zu großer Wert:

Es werden Werte unerwartet nicht geloggt.

Ich würde jetzt aus dem Bauch heraus eher zu 1s tendieren.

[AlCalzone]

Da stellt sich doch die Frage, ob "debouncen" die richtige Strategie fürs Loggen von Daten ist. Man will ja schließlich auch Daten speichern.

Sollte man dann nicht eher "throttlen"?

Bildhafter Vergleich: http://demo.nimius.net/debounce_throttle/

[apollon77]

Naja, throtteln ist mal in sofern drin dass man nur geänderte Werte speichern kann und sowas … also da ist ja schon ein bestimmtes Featureset da.

So gesehen war die bisherige Definition eher "Throtteln" weil schnelle Änderungen hintereinander nicht geloggt wurden ... aber es wurde der erste Wert geloggt und der letzte war halt verlohren ... Am Ende ist da sdie Änderung - wir loggen jetzt eher den letzten (also aktuellsten) als den ersten

[AlCalzone]

Die Definition von Throttle in obigem Link scheint mir eine Kombination aus dem zu sein, was du vorhast und was schon existiert:

• Reduktion der Datenmenge durch nicht-loggen zu schneller Änderungen

• Wenn eine Weile keine Änderungen kamen, den letzten empfangenen Wert speichern (selbst wenn dieser zuvor ignoriert wurde).

So wird einerseits eine Überlastung / zu große Datenmengen verhindert, andererseits aber garantiert, dass immer der "korrekte" Wert zuletzt in der DB steht.

Wäre das eine Überlegung wert?

[Homoran]

Ich habe gestern die Doku zu den Adaptern gemacht, aber noch nicht freigegeben.

IMHO ist genau das bereits integriert.

Du kannst auf "nur Änderungen" einstellen und trotzdem alle x Sekunden den gleichen Wert loggen.

Gruß

Rainer

[AlCalzone]

@Homoran:

Du kannst auf "nur Änderungen" einstellen und trotzdem alle x Sekunden den gleichen Wert loggen. `
Ohja, natürlich. Daran hatte ich nicht mehr gedacht.

[Pman]

@apollon77:

So gesehen war die bisherige Definition eher "Throtteln" weil schnelle Änderungen hintereinander nicht geloggt wurden … aber es wurde der erste Wert geloggt und der letzte war halt verlohren ... Am Ende ist da sdie Änderung - wir loggen jetzt eher den letzten (also aktuellsten) als den ersten `

Diesbezüglich ist mir noch etwas aufgefallen, ein Beispiel:

Zustand ist OFF. Bei einer sehr kurzen Änderung zu ON und wieder OFF wird nur OFF geloggt und die Änderung geht in der History verloren -> In diesem Fall müsste dann korrekterweise die Einstellung zu "gleichen Werten" berücksichtigt werden.

Bessere Lösung?:

Der erste Wert wird direkt ohne Timer geloggt (also wenn aktuell kein Debounce-Timer läuft) und erst danach wird der Debounce-Mechanismus gestartet. So gehen auch kurze Änderungen nicht verloren und es gibt auch keine Änderungen OFF -> OFF.

[Homoran]

@Pman:

Zustand ist OFF. Bei einer sehr kurzen Änderung zu ON und wieder OFF wird nur OFF geloggt und die Änderung geht in der History verloren `
stimmt! Aber liegt das wirklich an den History Einstellungen, oder bekommt ioBroker das vielleicht gar nicht mit? oder ist das die Entprellzeit mit Standard 10000msec.

ich hatte nämlich auch schon solche Fälle.

Gruß

Rainer