Hi Christian, Schick die Dumps mit Doku der Kanalnamen gerne an cpui...@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...@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 <cpui...@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...@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...@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...@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 >>>>>> <cpui...@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 <cpui...@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...@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...@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 >>>>>>>>>> <v...@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 >>>>>>>>>> >>>>>> >>
