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

[apollon77]

Auf Github (und ab irgendwann die Nacht auf auf npm/latest) gibt es die 3.0.6 ... da ist das mit dem Close Handling optimiert ... schau mal ob der Fehler immer noch kommt.

[bahnuhr]

@apollon77 sagte in Test Adapter Smartmeter 3.0.x:

Close Handling optimiert

Instanz aus:

host.Pi-Strom	2019-12-08 08:20:53.501	info	instance system.adapter.smartmeter.0 terminated with code 0 (OK)
host.Pi-Strom	2019-12-08 08:20:53.470	info	stopInstance system.adapter.smartmeter.0 killing pid 17463
host.Pi-Strom	2019-12-08 08:20:53.469	info	stopInstance system.adapter.smartmeter.0
host.Pi-Strom	2019-12-08 08:20:53.469	info	"system.adapter.smartmeter.0" disabled
host.Pi-Strom	2019-12-08 08:20:53.468	info	object change system.adapter.smartmeter.0
host.Asus-Buero	2019-12-08 08:20:35.918	info	object change system.adapter.smartmeter.0

Instanz ein:

smartmeter.0	2019-12-08 08:22:30.836	info	Received 7 values, 7 updated
smartmeter.0	2019-12-08 08:22:29.403	info	starting. Version 3.0.6 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v8.15.1
host.Pi-Strom	2019-12-08 08:22:27.017	info	instance system.adapter.smartmeter.0 started with pid 17477
host.Pi-Strom	2019-12-08 08:22:27.016	info	"system.adapter.smartmeter.0" enabled
host.Pi-Strom	2019-12-08 08:22:27.015	info	object change system.adapter.smartmeter.0
host.Asus-Buero	2019-12-08 08:22:08.499	info	object change system.adapter.smartmeter.0

Instanz (Kreis gedrückt - also aus und dann ein):

smartmeter.0	2019-12-08 08:23:13.143	info	Received 7 values, 7 updated
smartmeter.0	2019-12-08 08:23:12.299	info	starting. Version 3.0.6 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v8.15.1
host.Pi-Strom	2019-12-08 08:23:09.962	info	instance system.adapter.smartmeter.0 started with pid 17492
host.Pi-Strom	2019-12-08 08:23:07.475	info	instance system.adapter.smartmeter.0 terminated with code 0 (OK)
host.Pi-Strom	2019-12-08 08:23:07.442	info	stopInstance system.adapter.smartmeter.0 killing pid 17477
host.Pi-Strom	2019-12-08 08:23:07.442	info	stopInstance system.adapter.smartmeter.0
host.Pi-Strom	2019-12-08 08:23:07.440	info	object change system.adapter.smartmeter.0

Fazit:
sieht ok aus. Fehler ist weg.

[apollon77]

@bahnuhr cool. Danke. Der hatte vorher versucht den Serien port zu schließen obwohl der schon zu war ;-)

[MartyBr]

Hallo, ich habe nun am Wochenende meinen Adapter Smartmeter 1.x auf die Version 3.03 upgedatet. Ich habe damit gerechnet, dass der Adapter neue Datenpunkte mit den 2 _ anlegt. Die SQL Statements zum anpassen der in der SQL-DB geloggten Einträge lagen bereit.
Nach dem Update war ich dann (positiv) erstaunt, dass die alten DPs beibehalten wurden. Es war also nicht nötig, die Einträge in der SQL Datenbank anzupassen.

Jetzt habe ich auch das Update auf die 3.06 gemacht. Bisher läuft alles sehr gut.
Vielen Dank hier an diese Stelle an @apollon77 .

Hier ein Screenshot von der SQL-DB NACH dem Update:

[bahnuhr]

@MartyBr sagte in Test Adapter Smartmeter 3.0.x:

mit den 2 _ anlegt

Bei mir wurden beim Update die 2 _ angelegt.
Ich hatte somit die alten DP und auch die neuen mit den 2_.

[MartyBr]

@bahnuhr Das hatte ich auch befürchtet. Ich verstehe auch den Unterschied nicht. Ich habe ganz normal über den Admin das Update angestoßen. Da meine History Daten in der SQL liegen, habe ich vorher nach einer Möglichkeit gesucht, diese anpassen zu können.
Hier hatte mir @a200 geholfen.

[bahnuhr]

@MartyBr sagte in Test Adapter Smartmeter 3.0.x:

Das hatte ich auch befürchtet.

Dein Screenshot zeigt aber sql, oder ?
Die Datenpunkte mit den 2 _ werden aber doch bei den Objekten angelegt.
In sql habe ich noch die damaligen * als Alias drin.

[MartyBr]

@bahnuhr Ja, ich logge alle History Daten in den SQL-Adapter.

[MartyBr]

Habe gerade gesehen, dass in den Objekten einige mit den zwei Unterstrichen angelegt wurden. Das ist hoffentlich nicht problematisch, ich logge nur die Zahlenwerte:

[bahnuhr]

Na, siehst du.
Und nur diese (mit 2_) enthalten zukünftig Daten.

Instanz aus.
Lösche mal die Objekte
Instanz ein.

Dann hast du nur die DP die auch Werte enthalten.
Und bei diesen dann sql.

Wenn du die alten Werte in sql erhalten willst, dann alias verwenden.

[bahnuhr]

sieht dann so aus:

[MartyBr]

@bahnuhr Der zweite Zähler enthält andere Werte; hier gibt es die doppelten Unterstriche nicht:

[a200]

@MartyBr solange du nicht VORHER schon die DP, die JETZT zwei Unterstriche haben, geloggt hast, spielt das für dich keine Rolle. Das ganze war nur nötig um die bisher gespeicherten Daten zu behalten und mit den neuen Namen weiter zu loggen.

[MartyBr]

@a200
Ich logge ja seit 9 Monaten die Daten. Daher wäre es nötig gewesen. Aber die Zählerstände beider Zähler haben weiter den gleichen DP. Nur die DP "Kumuliertes Maximum xxx" haben die neuen DPs bekommen. Diese Werte logge ich nicht, nur den "Zählerstand XX". Di Auswertung mache ich Sourceanalyticx.
Macht ihr das anders?

[MartyBr]

@bahnuhr
ich habe das sprechend gemacht:

[MartyBr]

Hier mal alle DPs der beiden Zähler:

[apollon77]

Ob und welche mit zwei Unterstrichen neu angelegt werden hängt davon ab wie die ID der Objekte nach obis aufgebaut sind. D.h. es passiert nicht bei allen, sondern nur bei einigen.

[bahnuhr]

@MartyBr sagte in Test Adapter Smartmeter 3.0.x:

ich habe das sprechend gemacht:

Heißt der Datenpunkt wirklich "Haushaltsstrom" ?

Ich habe smartmeter schon lange installiert.
Und auch immer mit sql gespeichert.

früher hieß der DP: smartmeter.0.1-0:2_8_0*255.value
Dann war der * nicht mehr zulässig.
daraus wurde dann: smartmeter.0.1-0:2_8_0_255.value
und nun eben: smartmeter.0.1-0:2_8_0__255.value

In sql sind sie aber weiterhin bei * gespeichert.
Deshalb ja auch der alias.

[MartyBr]

@bahnuhr Das ist ein Alias im Adapter SmartMeter. Der loggt dann (bei mir) die Daten unter "Haushaltsstrom" in der SQL Datenbank.
Ich versuche das vom Adapter zu entkoppeln.

[MartyBr]

Ich muss mich jetzt für 2 Stunden abmelden, das Mittagessen ruft! :poultry_leg: