[vz-users] aggregate error minute level

[Christian S]

Ich kann jetzt def sagen das es bei mir nur mit Kanälen kommt bzgl
Temperatur.
Hab 3 Kanäle erstellt:
1. Bekommt die Werte aus node-red (quelle FHEM)
2. Bekommt die Werte per Linux Script (quelle OWS)
3  Bekommt die Werte aus node-red (quelle OWS

Habe jetzt den OWS Node-Red Kanal gelöscht und der Fehler ist weg.
Vorher Nachher SQL Dumps hab ich gemacht. Will die aber nicht direkt in der
MailingListe posten. Einfach mich direkt anschreiben wenn interesse besteht.


Grüße





Am So., 19. Jan. 2020 um 14:08 Uhr schrieb Andreas Goetz <cpuidle at gmail.com
>:

> Alles sehr merkwürdig. Mir viele nur ein Daten vor Fehler sichern, Skript
> anwerfen, wenn Fehler nochmal sichern. Dann könnte ich mal auf den
> Unterschied schauen anstatt nur aus dem Fehlerbild zu versuchen woran es
> liegt.
>
> Oder wir ignorieren es weiter ;)
>
> Viele Grüße, Andreas
>
>
> On 19. Jan 2020, at 09:02, Christian S <schnellrieder.cs at gmail.com> wrote:
>
> Hi.
>
> Vielleicht noch als Input. Hatte jetzt immer Ruhe von dem Fehler... bis
> ich wieder den Temp Kanal aktiviert habe. Dieser Kanal wird von einem
> Script befüllt das von OWM die Daten bezieht und dann in die Datenbank
> schreibt.
> Vor ein paar hab ich das script wieder aktiviert und zack... am nächsten
> Tag schon wieder der Aggregate Fehler. Hab jetzt den gesamten Kanal
> gelöscht und der Fehler ist auch wieder weg.
>
> Grüße
>
> Am Do., 31. Okt. 2019 um 13:39 Uhr schrieb Christian S <
> schnellrieder.cs at gmail.com>:
>
>> Hallo Andreas.
>>
>> Immer noch nix. Also ja ich denke du kannst es zu den Akten legen.
>>
>> Grüße
>>
>> Am Do., 24. Okt. 2019 um 10:33 Uhr schrieb Christian S <
>> schnellrieder.cs at gmail.com>:
>>
>>> Hallo.
>>>
>>> Kann ich aktuell nicht direkt beantworten: Ich hab damals ja auf mariaDB
>>> umgestellt und ich denke das ich dann den Eintrag in cron für die Minuten
>>> abgestellt habe weil mich im Fehlerfall der Server mit Mails voll gespamt
>>> hat.
>>>
>>> Ich hab den Eintrag jetzt mal wieder aktiviert. Bis jetzt war nix.
>>>
>>> Grüße
>>>
>>> Am Mi., 23. Okt. 2019 um 22:47 Uhr schrieb Andreas Goetz <
>>> cpuidle at gmail.com>:
>>>
>>>> Hallo Christian,
>>>>
>>>> ich habe das immer noch auf meiner Todoliste- ist der Fehler irgendwann
>>>> nochmal aufgetreten? Falls nein würde ich ihn jetzt als “sporadisches MySQL
>>>> Problem” zu den Akten legen…
>>>>
>>>> Viele Grüße, Andreas
>>>>
>>>>
>>>> On 12. Jul 2019, at 13:35, Andreas Götz <cpuidle at gmail.com> wrote:
>>>>
>>>> Ziemlich sicher nicht- ich sehe den Fehler auch, finde aber keine
>>>> Ursache :(
>>>>
>>>> Viele Grüße,
>>>> Andreas
>>>>
>>>> Am 12.07.2019 um 07:59 schrieb Christian S <schnellrieder.cs at gmail.com
>>>> >:
>>>>
>>>> So kleines Update.
>>>>
>>>> Also so langsam glaub ich eher das der Wurm eher in der Datenbank
>>>> selbst war.
>>>> Nach einer komplett zerstören MYSQL installation und einem Versuch wo
>>>> die Datenbank selbst dann auch defekt war denke ich hab ich den Umstieg
>>>> geschaft.
>>>>
>>>> Warum auch immer und da bin ich nur durch einen Zufall draufgekommen
>>>> hatte die Datenbank nicht die altuelle Version. Nach einem Upgrade mit
>>>> "mysql_upgrade" war der Umstieg auf mariadb wirklich easy. Vielleicht liegt
>>>> da auch die Ursache für das eigentliche Problem.
>>>>
>>>> Grüße
>>>>
>>>> Am Mo., 8. Juli 2019 um 07:23 Uhr schrieb Christian S <
>>>> schnellrieder.cs at gmail.com>:
>>>>
>>>>> Danke Daniel.
>>>>>
>>>>> Hat leider nicht so ganz geklappt auf den ersten Versuch ;)
>>>>> Kann da auch nicht sagen warum aber der Dump den ich für Andi gemacht
>>>>> habe wurde nur ein Bruchteil der Daten angenommen. Leider kann ich jetzt
>>>>> nicht direkt mit Fehlermeldungen aufwarten. Aber nach 4 Stunden wollt ich
>>>>> nur zurück zu mysql wo auch der dump restore ganz normal funktioniert hat.
>>>>>
>>>>> Werd mir aber die Tage nochmal die Zeit nehmen und es nochmal testen.
>>>>>
>>>>> Grüße
>>>>>
>>>>>
>>>>> Am So., 7. Juli 2019 um 18:38 Uhr schrieb Daniel Lauckner <vz at jahp.de
>>>>> >:
>>>>>
>>>>>> Hallo,
>>>>>>
>>>>>>
>>>>>> am Sonntag, 7. Juli 2019 um 18:05 hat Christian S geschrieben:
>>>>>> > Ich werd mich mal einlesen in Maria DB und wie ich hier am besten
>>>>>> > meine beiden Anwendungen (Nextcloud und VZ) auf MariaDB umstelle.
>>>>>>
>>>>>> Wenn du ein Backup mit einem SQL-Client ziehst (sqldump, dbcopy)
>>>>>> liegen die Daten als Klartext vor und werden auch als Klartext wieder
>>>>>> eingespielt. Die interne Unterschiede der DB spielen also keine
>>>>>> Rolle.
>>>>>>
>>>>>> Das schöne an MariaDB ist das es sogar die selbe PHP-Schnittstelle
>>>>>> pdo_mysql nutzt. Also von der Anwendungsseite her (wohl auch bei
>>>>>> Nextcloud) keine Anpassungen erforderlich sind.
>>>>>>
>>>>>> Anwendungen aus, Backup, alte DB aus, neue DB an, Restore, Anwendungen
>>>>>> an.
>>>>>>
>>>>>>
>>>>>> mfg Daniel
>>>>>>
>>>>>>
>>>>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20200204/728484e0/attachment-0001.html>