wichtiges UPDATE für controller 7.2.2 im stable

[sissiwup]

sql-0	2016-11-07 08:11:43.903	error	Cannot insert INSERT INTO iobroker.ts_bool (id, ts, val, ack, _from, q) VALUES(535, 2016000, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '535-2016000' for key 'PRIMARY'
sql-0	2016-11-07 08:10:44.202	error	Cannot insert INSERT INTO iobroker.ts_bool (id, ts, val, ack, _from, q) VALUES(535, 2016001, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '535-2016001' for key 'PRIMARY'
hm-rpc-0	2016-11-07 08:10:13.152	info	setValue ["LEQ1274926:1","STATE",true] BOOL
hm-rpc-0	2016-11-07 08:10:06.740	info	setValue ["LEQ1274912:1","STATE",true] BOOL
hm-rpc-0	2016-11-07 08:09:43.914	info	setValue ["LEQ1274951:1","STATE",true] BOOL
sql-0	2016-11-07 08:08:44.358	error	Cannot insert INSERT INTO iobroker.ts_bool (id, ts, val, ack, _from, q) VALUES(535, 2016000, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '535-2016000' for key 'PRIMARY'

Hallo, sieht der Timestamp nicht etwas merkwürdig aus?

[apollon77]

Auf welcher Version ist das ganze? Wann ist das ganze passiert= Gabs nen Neustart davor oder neustart vom m-rega/rpc-Adapter?

Ich hatte solche Daten (2016000) auch schonmal gesehen … es gibt scheinbar bestimmte Datenpunkte wo aus irgendwlechen Gründen so ein komisches Datum erzeugt wird

[sissiwup]

Hallo,

Neuste Version vom SQL-Adapter (von letzter Woche)

Kein Neustart sondern kommt sporadisch.

Wie man sieht auch mit unterschiedlichen Timestamps:

2016000

2016001

Ist aber scheinbar immer ein boolean

[apollon77]

Soweit ich gesehen habe erhöht der SQL.-Adapter teilweise timestamps um "1" um duplicates eigentlich auszuschliessen … also die mit 1 am Ende ist wohl das gleiche wie da smit 0. Frage ist welcher Datenpunkt es ist.

Kannst du mal in der DB schauen was in iobroker.datapoints der Eintrag mit ID 535 ist?

SELECT * from iobroker.datapoints where id=535 (oder so)

[Bluefox]

I'm db gibt es keine ID. Als id wird Zeitstempel + State ID.

201601 sieht nach falsches Datum aus.

[apollon77]

Meine Idee war rauszufinden welche Datenpunkt das ist.

Ich hatte so einen Effekt auch mal gesehen bei Datenpunkten aus rega glaube ich

[sissiwup]

Hallo,

ist folgender Datenpunkt:

535,hm-rpc.0.NEQ0875426.4.FAULT_REPORTING-7_ALARM,2

Ist ein neues Heizkörperthermostat

Datapoint:

535,2.016.000,false,true,3,0

[sissiwup]

Hallo,

habe die Protokollierung für diesen Datenpunkt jetzt deaktiviert.

[Superdad]

Hallo,

ist denn was raus gekommen betreffs der Fehlermeldung?

Bekomme das auch angezeigt bei einem neuen Heizkörperthermostat.

Gruss

[sissiwup]

Hallo,

nein, leider nicht. Es ist ein Datenpunkt, den man rausnehmen muss, da hier das Datum falsch ist.

Ist das Fault_Reporting (siehe oben)

[Segway]

Hallo,

bevor ich was neues aufmache, muss ich mal nachfragen, da ich den gleichen Fehler / Error in meinem Log habe.

Es sind so ziemlich alles Datenpunkte mit dem Wert –> STICKY_UNREACH_ALARM vom hm-rpc.1 Adapter.

Die Lösung kann ja jetzt nicht sein das Logging zu deaktivieren oder ? Warum kommt denn der Fehler ?

Was ist das überhaupt für ein Datenwert ?

[apollon77]

naja, wenn Du nicht mal weisst was es für ein Datenpunkt ist, warum solltest Du Ihn dann loggen wollen ;-(

Das ist ein spezieller Datenpunkt der nur gesetzt wird wenn der STICKY_UNREACH Fehler kommt.

Ich hab die bei mir auch rausgenommen

[Segway]

Ja hatte die jetzt auch rausgenommen nachdem ich mal gelesen habe was das fuer Werte sind.

Fuer mich als belanglos und nicht Historie-wuerdig eingestuft :-)

Gesendet von iPhone mit Tapatalk

[dtp]

Hallo,

wie finde ich raus, um welche Datenpunkte es sich hier handelt?

[dtp]

Keine eine Idee, wie ich die entsprechenden Datenpunkte finde, die diese Fehlermeldungen hervorrufen?