[vz-users] aggregate error minute level

Mi Feb 5 20:00:49 CET 2020

Hi Christian,

Schick die Dumps mit Doku der Kanalnamen gerne an cpuidle at gmx.de. Momentan aber ganz kleine Prio da ich erstmal meine Wallboxsteuerung ans fliegen bringen möchte. 

OT: falls irgendjemand eine Wallbe (oder andere Wallbox) PV-geführt steuern möchte und heute mit OpenWB nicht glücklich wird kann sich gerne https://github.com/andig/evcc anschauen. 

Viele Grüße, Andreas 

> Am 04.02.2020 um 15:28 schrieb Christian S <schnellrieder.cs at gmail.com>:
> 
> 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/20200205/9983c618/attachment.html>