Re: [vz-users] kein ttyUSB0 mti fertigem Image
Hallo. Was sagt denn ein: ls /dev/serial/by-id/* Grüße Am Do., 18. Juni 2020 um 11:40 Uhr schrieb Daniel Lauckner : > Hallo, > > > an der Stelle würde ich es mit rpi-update versuchen. > https://www.elektronik-kompendium.de/sites/raspberry-pi/2006061.htm > > > mfg Daniel > >
Re: [vz-users] probleme mit fertigem image raspi 3
Hallo. >Bei mir steht Leistungswerte (el. Energy) als Typ powersensor was muss denn dort eingestellt werden ? Wirf mal einen Blick auf die Liste der Kanaltypen. Ich bin mir sicher. Du wirst fündig. Es steht sogar indirekt in der Antwort von Andreas... Grüße Am Fr., 6. März 2020 um 10:27 Uhr schrieb wilhelm : > Am 05.03.2020 um 22:46 schrieb Andreas Goetz: > > Hallo Dieter, > > > > Probiers doch einfach mal aus! Bei deinen Zählerständen stimmt der > Kanaltyp nicht- bitte ändern, dann siehst Du auch einen Leistungsverlauf. > > > > Viele Grüße, Andreas > > > >> Am 05.03.2020 um 22:32 schrieb wilhelm : > >> > >> Am 05.03.2020 um 21:34 schrieb Daniel Lauckner: > >>> Hallo, > >>> > >>> > >>> am Mittwoch, 4. März 2020 um 22:08 hat wilhelm geschrieben: > kann es denn sein wenn ich die putty session beende das der Prozess > dann > gestoppt wird ? normalerweise doch nicht ? > >>> Doch. Ein Prozess der von der Kommandozeile gestartet wird und im > >>> Vordergrund läuft wird beendet wenn man sich abmeldet. > >>> > >>> Deswegen ist vzlogger im Image ja auch so eingerichtet das er als > >>> Hintergrundprozess (ohne Kommandozeile) läuft. > >>> Dazu muss er aber fehlerfrei anlaufen. Richtige Konfig und so... > >>> > >>> > >>> mfg Daniel > >>> > >> danke für alle hinweise womit ich den Vzlogger zum laufen bringen > konnte. > >> Nun möchte ich aber folgendes sehen da ich eine pv anlage habe, > >> - Welchen Verbrauch habe ich zu einem bestimmten zeitpunkt ( als Grafik) > >> - Welche Menge produziere( speise ich ein) ich im gleichen Zeitraum ( > als Grafik) > >> derzeit werdenm mir nur die Zählerstände mitgeteilt was mehr oder > minder eine fast gerade Linie gibt. > >> Ich kann nicht erkennen wenn z. B ein großer Verbraucher eingeschaltet > wird wie sich das auswirkt. > >> Ist dies möglich über virtuelle Kanäle z.B. durch Subtraktion einzelner > Kanäle oder welche möglichkeiten gibt es ? > >> MfG > >> dieter > Bei mir steht Leistungswerte (el. Energy) als Typ powersensor was muss > denn dort eingestellt werden ? > >
Re: [vz-users] aggregate error minute level
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 : > 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 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 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 >>> >: >>>> >>>> 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 >>>> >: >>>>> >>>>>> 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 >>>>>> >>>>>> >>>> >
Re: [vz-users] aggregate error minute level
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 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 : >>> >>> 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 : >>>> >>>>> 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 >>>>> >>>>> >>>
Re: [vz-users] verschiedene Werte trotz gleicher Linie
>Unter Initialverbrauch gebe ich quasi den aktuellen Zählerstand ein? Zb. Ich hab den Stand eingegeben wo ich den Zähler übernommen hab. Am Mi., 25. Dez. 2019 um 15:00 Uhr schrieb Christian Wimmer < christ...@nega.at>: > >In der Kanaltabelle, wenn in den Eigenschaften ein Initialwert > eingetragen ist. > > > > Unter Initialverbrauch gebe ich quasi den aktuellen Zählerstand ein? > > >
Re: [vz-users] verschiedene Werte trotz gleicher Linie
Ich hab den selben Zähler und kann bestätigen das der Faktor 1000 passt. Adding reading to queue (value=22067043.00 ts=1577281533000) Ergibt eben einen Zählerstand von 22067.043 Am Mi., 25. Dez. 2019 um 14:41 Uhr schrieb Frank Richter < frank.richte...@gmail.com>: > Standard ist /var/log/vzlogger.log, keine Ahnung wo /dev/null bei dir > herkommt. > > Aber hast du mal die vorgeschlagene Änderung bzgl. aggtime probiert? Bin > mir ziemlich sicher dass das schon reicht. Die Auflösung in den > Kanaleigenschaften passt IMHO, um Faktor 1000 ist die auf keinen Fall > daneben. > > Grüße > Frank > > Christian Wimmer schrieb am Mi., 25. Dez. 2019, 14:30: > >> Hallo >> >> >Ist in der Konfigurationsdatei definiert. >> In der vzlogger.conf steht "log": "/dev/null", >> >> >> Unter /var/log/ finde ich kein vzlogger.conf >> >Natürlich nicht: .conf steht für configuration, du suchst vzlogger.log >> >> Ich habe mich nach dieser Seite orientiert. >> https://wiki.volkszaehler.org/howto/debug?s[]=log >> Da steht " was steht im logfile (/var/log/vzlogger.conf bzw. >> /tmp/vzlogger.log)" >> >> Ich finde nur unter /var/log/ eine vzlogger.log >> Die ist vom 23.12.19 00:00:02 und hat 0 kb >> >> >> LG >> >
Re: [vz-users] VZ mit Energie AG OÖ
Ändert aber nix an dem Umstand das du hier ein , zuviel hast.
So sollte es gehen:
{
"retry": 0,
"daemon": true,
"verbosity": 15,
"log": "/var/log/vzlogger.log",
"local": {
"enabled": false,
"port": 80,
"index": true,
"timeout": 0,
"buffer": 0
},
"meters": [
{
"enabled": true,
"allowskip": false,
"interval": -1,
"aggtime": -1,
"aggfixedinterval": false,
"channels": [
{
"api": "volkszaehler",
"uuid": "068bdda0-243d-11ea-9e06-116dc20589ab",
"identifier": "1.8.0",
"middleware": "http://localhost/middleware.php";,
"aggmode": "none",
"duplicates": 0
},
{
"api": "volkszaehler",
"uuid": "068bdda0-243d-11ea-9e06-116dc20589ab",
"identifier": "2.8.0",
"middleware": "http://localhost/middleware.php";,
"aggmode": "none",
"duplicates": 0
}
],
"protocol": "oms",
"device": "/dev/ttyUSB0",
"baudrate": 9600,
"key": "hier steht normal der Key",
"mbus_debug": false
}
]
}
Man beachte diese Stelle:
"duplicates": 0
}
],
da hast du:
"duplicates": 0
},
],
Grüße
Am So., 22. Dez. 2019 um 14:07 Uhr schrieb Christian Wimmer <
christ...@nega.at>:
> Ich habe die Beispielkonfiguration für Oberösterreich von hier genommen.
>
>
>
>
> https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511_in_oberoesterreich
>
>
>
>
>
> *Von:* volkszaehler-users <
> volkszaehler-users-boun...@demo.volkszaehler.org> *Im Auftrag von *Christian
> S
> *Gesendet:* Sonntag, 22. Dezember 2019 08:29
> *An:* volkszaehler-users
> *Betreff:* Re: [vz-users] VZ mit Energie AG OÖ
>
>
>
> Hallo.
>
>
>
> Deine vzlogger.conf passt nicht lt.
> https://volkszaehler.github.io/vzlogger/
>
>
>
> Grüße
>
>
>
>
>
> Am So., 22. Dez. 2019 um 07:55 Uhr schrieb Daniel Lauckner :
>
> Hallo,
>
>
> am Samstag, 21. Dezember 2019 um 23:51 hat Christian Wimmer geschrieben:
> > Ich komme mit dem VZ nicht weiter.
>
> Was hast du denn überhaupt für einen Zähler?
>
>
> > Könnt sich eventuell wer mit Teamviewer auf meinen PC hängen und helfen?
>
> Sowas mach ich nicht weil ich von dem Prinzip Forum/Mailingsliste
> überzeugt bin.
>
>
> mfg Daniel
>
>
Re: [vz-users] VZ mit Energie AG OÖ
Hallo. Deine vzlogger.conf passt nicht lt. https://volkszaehler.github.io/vzlogger/ Grüße Am So., 22. Dez. 2019 um 07:55 Uhr schrieb Daniel Lauckner : > Hallo, > > > am Samstag, 21. Dezember 2019 um 23:51 hat Christian Wimmer geschrieben: > > Ich komme mit dem VZ nicht weiter. > > Was hast du denn überhaupt für einen Zähler? > > > > Könnt sich eventuell wer mit Teamviewer auf meinen PC hängen und helfen? > > Sowas mach ich nicht weil ich von dem Prinzip Forum/Mailingsliste > überzeugt bin. > > > mfg Daniel > >
Re: [vz-users] plötzlicher logging stop
Was man erkennen kann (und da braucht man wirklich eine gute Brille) ist das sich die USB Devices abmelden. Also Kabel oder /USB Host Problem. Wackel einfach mal am Kabel und schau via demesg ob sich was tut. Grüße Am Do., 12. Dez. 2019 um 05:17 Uhr schrieb René W : > Moin > Ich weiß nicht warum die Mail nochmal geschickt wurde. Bitte ignorieren. > Ich warte zur Zeit auf den nächsten Stopp. > Bitte entschuldigt die Unannehmlichkeiten. > > Frank Richter schrieb am Mi. 11. Dez. 2019 um > 23:58: > >> Die Mail war anscheinend 2 Tage unterwegs ;-) >> >> Grüße >> Frank >> >> Am Mi., 11. Dez. 2019 um 21:44 Uhr schrieb Andreas Goetz < >> cpui...@gmail.com>: >> >>> Ich denke es hat sich nichts geändert: >>> >>> - Dein Screenshot ist erneut unleserlich >>> - Dein Service sollte auf Restart=always stehen um wieder anzulaufen und >>> Lücken zu vermeiden >>> - Du solltest im Syslog rausfinden warum er abbricht >>> >>> Es hilft leider nicht die gleichen Fragen von vorne zu iterieren ;) >>> >>> Letztlich wäre es toll auf das alte Thema zu antworten statt ein Neues >>> aufzumachen :/ >>> >>> Viele Grüße, >>> Andreas >>> >>> >>> On 9. Dec 2019, at 07:14, René W. wrote: >>> >>> Guten Morgen, >>> >>> mein vzlogger hat nun zum zweiten mal getoppt zu loggen. Es läuft über >>> ein RPi3 mit externer Synology Datenbank. Nach einem reboot oder manuellen >>> Start des Dienstes läuft der Log weiter. Im frontend sind aber Lücken zu >>> sehen. >>> Da der verbose debug recht niedrig ist, habe ich hier eine log ausm >>> /var/log/sys.log >>> >>> >>> Ich werde da nicht ganz schlau daraus und was ich als nächstes machen >>> sollte. Könnt ihr mir helfen? >>> >>> Gruß René >>> >>> >>>
Re: [vz-users] Stromzähler OÖ
Hallo. Ja ich Grüße Christian Wimmer schrieb am Mi., 4. Dez. 2019, 22:10: > Hallo > > > > Gibt es hier User, die den VZ am Stromzähler der Energie AG verwenden? > > > > Danke > > >
Re: [vz-users] aggregate error minute level
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 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 : >> >> 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 : >>> >>>> 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 >>>> >>>> >>
Re: [vz-users] aggregate error minute level
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 : > 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 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 : > > 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 : >> >>> 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 >>> >>> >
Re: [vz-users] aggregate error minute level
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 : > >> 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 >> >>
Re: [vz-users] Ausgänge programmieren
Hallo. Ich würde sowas mit Node-red machen. Grüße bconrad schrieb am Do., 11. Juli 2019, 17:19: > Hallo, > > > ich habe bei mir zwei USB-IR-Leseköpfe im Betrieb an einen Raspberry pi > jetzt möchte ich gerne das z.b bei einer Aktuellen Leistung von 500 Watt > ein Ausgang geschaltet wird um z.b zu Signalisieren das in moment zu > viel Strom Verbraucht wird ist sowas irgendwie möglich ? > > Wenn ja haben sie vieleicht ein passendes skript . ? > > > Mit freundlichen Grüßen > >
Re: [vz-users] aggregate error minute level
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 : > 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 > >
Re: [vz-users] aggregate error minute level
Ja auf dem Rechner ist mysql installiert: root@service-uplink:/home/nas# mysql -V mysql Ver 14.14 Distrib 5.7.26, for Linux (x86_64) using EditLine wrapper Ich werd mich mal einlesen in Maria DB und wie ich hier am besten meine beiden Anwendungen (Nextcloud und VZ) auf MariaDB umstelle. Grüße Am So., 7. Juli 2019 um 17:50 Uhr schrieb Andreas Goetz : > Hi Christian, > > Ich checks leider nicht, hier die Diskussion: > > > https://stackoverflow.com/questions/56923720/why-does-using-replace-over-select-cause-div-by-zero-exception > > Mal sehen, ob ein MySQL Guru eine Idee hat. Hast Du mal versucht, MariaDB > zu nutzen oder hast Du tatsächlich- wie ich auf dem Testrechner- überhaupt > MySQL im Einsatz? > > Viele Grüße, Andreas > > > On 7. Jul 2019, at 17:36, Andreas Goetz wrote: > > Perfekt, nach einigem Installationsgerödel (Laptop lange nicht benutzt) > kann ichs nachvollziehen, für genauere Analyse brauche ich aber etwas Zeit. > > Viele Grüße, Andreas > > > On 7. Jul 2019, at 10:45, Christian S wrote: > > Hallo Andreas. > > Der Fehler ist wieder gekommen. > Log File und Dump liegen auf: > https://nextcloud.service-uplink.de/s/9ddDJJqSPL9XxEP > > > Grüße > > Am Do., 4. Juli 2019 um 10:15 Uhr schrieb Andreas Götz >: > >> Kein Grund für eine Entschuldigung- Du hast das Problem doch perfekt >> gelöst! >> >> Viele Grüße, >> Andreas >> >> Am 04.07.2019 um 10:03 schrieb Christian S : >> >> Ist notiert und sorry nochmal :( >> >> Am Do., 4. Juli 2019 um 10:01 Uhr schrieb Andreas Götz > >: >> >>> Bitte schick mir direkt -v und dump wenn es wieder passiert. Das kam >>> jetzt 2x vor- irgendwo scheint der Wurm drin zu sein, mir fehlen aber >>> ausreichend Informationen den zu beseitigen. >>> >>> Viele Grüße, >>> Andreas >>> >>> Am 04.07.2019 um 09:58 schrieb Christian S : >>> >>> Danke Andreas für deine schnelle Antwort. >>> >>> Ich war leider schon zu schnell und hab mal in der Zwischenzeit gelesen >>> welche commandos "aggregate" noch so bietet und ein "php /var/www/ >>> volkszaehler.org/bin/aggregate rebuild" hat scheinbar das Problem >>> beseitigt. >>> >>> Die Datenbank ist eine "mysql" Datenbank. Wenn du den dump aber noch >>> immer brauchst lass ich dir den gerne zukommen. >>> Auf jeden Fall werd ich mir das mit -v merken und das nächste mal etwas >>> langsamer machen. >>> >>> Grüße >>> >>> >>> >>> Am Do., 4. Juli 2019 um 08:49 Uhr schrieb Andreas Götz < >>> cpui...@gmail.com>: >>> >>>> Kannst Du das Kommando bitte nochmal mit -v ausführen damit ich den >>>> Verursacher der Fehlermeldung sehr? >>>> >>>> Wäre es evtl möglich mir einen Dump Deiner DB zukommen zu lassen? Was >>>> für eine DB ist das? >>>> >>>> Viele Grüße, >>>> Andreas >>>> >>>> Am 04.07.2019 um 08:25 schrieb Christian S >>> >: >>>> >>>> >>>> Hallo. >>>> >>>> Seit Tagen bekomme ich beim Ausführen von "aggregate" immer einen >>>> Fehler (nur auf dem Level "minute"). >>>> In den Log Files hätte ich jetzt nichts gefunden. Unten der Fehler im >>>> Detail aber so richtig schlau werde ich nicht daraus. >>>> >>>> Grüße >>>> >>>> root@service-uplink:/home/nas# php /var/www/ >>>> volkszaehler.org/bin/aggregate run -m delta -l minute >>>> Performing 'delta' aggregation on 'minute' level >>>> >>>> [>---] 0% < 1 sec/< 1 sec 0 channels >>>> [===>] 11% < 1 sec/< 1 sec 1 channels >>>> [==>-] 22% < 1 sec/< 1 sec 2 channels >>>> [=>--] 33% < 1 sec/< 1 sec 3 channels >>>> [>---] 44% < 1 sec/< 1 sec 4 channels >>>> In AbstractMySQLDriver.php line 106: >>>> >>>> An exception occurred while executing 'REPLACE INTO aggregate >>>> (channel_id, type, timestamp, value, count) SELECT channel_ >>>> id, ? AS type, MAX(agg.timestamp) AS timestamp, COALESCE( >>>> SUM(agg.val_by_time) / (MAX(agg.timestamp) - MIN(agg.prev_times >>>> tamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS count FROM ( >>>>
Re: [vz-users] aggregate error minute level
Hallo. Ne der min Job läuft bei mir alle 10 min und min kann aktuell gar nicht ausgeführt werden. Kommt immer dieser Fehler. Grüße Am So., 7. Juli 2019 um 16:47 Uhr schrieb Andreas Goetz : > Ohne dass ich schon auf Fehlersuche war mal ein Gedanke: lässt Du die Jobs > auch minütlich laufen? Falls ja- ist sichergestellt, dass der eine endet > bevor der andere startet? Sonst könnte ich mir divide by 0 im SQL schon > vorstellen. Lass die mal bitte nur all 10-15min laufen, das sind ja auch > nur 10x60 Messwerte mehr die unaggregiert je Kanal rumliegen. > > Viele Grüße, Andreas > > > Am 07.07.2019 um 16:01 schrieb Daniel Lauckner : > > > > Hallo, > > > > > > am Sonntag, 7. Juli 2019 um 12:15 hat Frank Richter geschrieben: > >> brauchst du Level minute wirklich, d.h. loggst du Werte mit > >> Intervall << 60s? Ich komme mit hour und day ganz gut klar, und die > >> Tabelle aggregate bleibt deutlich kompakter. > > > > Die cronjobs sind im Image ab Haus bereits aktiv und es wird > > natürlich auch Minutenweise aggregiert. > > > > > > mfg Daniel > > >
Re: [vz-users] aggregate error minute level
Hallo Frank. Ja ich loge wirklich mit einer Sekunde. Ob es das wirklich braucht steht auf nen anderen Blatt. Grüße Am So., 7. Juli 2019 um 12:15 Uhr schrieb Frank Richter < frank.richte...@gmail.com>: > Hi Christian, > > natürlich sollte das nicht auftreten, aber abgesehen davon: brauchst du > Level minute wirklich, d.h. loggst du Werte mit Intervall << 60s? Ich komme > mit hour und day ganz gut klar, und die Tabelle aggregate bleibt deutlich > kompakter. > > Viele Grüße > Frank > > Christian S schrieb am So., 7. Juli 2019, > 10:45: > >> Hallo Andreas. >> >> Der Fehler ist wieder gekommen. >> Log File und Dump liegen auf: >> https://nextcloud.service-uplink.de/s/9ddDJJqSPL9XxEP >> >> >> Grüße >> >> Am Do., 4. Juli 2019 um 10:15 Uhr schrieb Andreas Götz > >: >> >>> Kein Grund für eine Entschuldigung- Du hast das Problem doch perfekt >>> gelöst! >>> >>> Viele Grüße, >>> Andreas >>> >>> Am 04.07.2019 um 10:03 schrieb Christian S : >>> >>> Ist notiert und sorry nochmal :( >>> >>> Am Do., 4. Juli 2019 um 10:01 Uhr schrieb Andreas Götz < >>> cpui...@gmail.com>: >>> >>>> Bitte schick mir direkt -v und dump wenn es wieder passiert. Das kam >>>> jetzt 2x vor- irgendwo scheint der Wurm drin zu sein, mir fehlen aber >>>> ausreichend Informationen den zu beseitigen. >>>> >>>> Viele Grüße, >>>> Andreas >>>> >>>> Am 04.07.2019 um 09:58 schrieb Christian S >>> >: >>>> >>>> Danke Andreas für deine schnelle Antwort. >>>> >>>> Ich war leider schon zu schnell und hab mal in der Zwischenzeit gelesen >>>> welche commandos "aggregate" noch so bietet und ein "php /var/www/ >>>> volkszaehler.org/bin/aggregate rebuild" hat scheinbar das Problem >>>> beseitigt. >>>> >>>> Die Datenbank ist eine "mysql" Datenbank. Wenn du den dump aber noch >>>> immer brauchst lass ich dir den gerne zukommen. >>>> Auf jeden Fall werd ich mir das mit -v merken und das nächste mal etwas >>>> langsamer machen. >>>> >>>> Grüße >>>> >>>> >>>> >>>> Am Do., 4. Juli 2019 um 08:49 Uhr schrieb Andreas Götz < >>>> cpui...@gmail.com>: >>>> >>>>> Kannst Du das Kommando bitte nochmal mit -v ausführen damit ich den >>>>> Verursacher der Fehlermeldung sehr? >>>>> >>>>> Wäre es evtl möglich mir einen Dump Deiner DB zukommen zu lassen? Was >>>>> für eine DB ist das? >>>>> >>>>> Viele Grüße, >>>>> Andreas >>>>> >>>>> Am 04.07.2019 um 08:25 schrieb Christian S >>>> >: >>>>> >>>>> >>>>> Hallo. >>>>> >>>>> Seit Tagen bekomme ich beim Ausführen von "aggregate" immer einen >>>>> Fehler (nur auf dem Level "minute"). >>>>> In den Log Files hätte ich jetzt nichts gefunden. Unten der Fehler im >>>>> Detail aber so richtig schlau werde ich nicht daraus. >>>>> >>>>> Grüße >>>>> >>>>> root@service-uplink:/home/nas# php /var/www/ >>>>> volkszaehler.org/bin/aggregate run -m delta -l minute >>>>> Performing 'delta' aggregation on 'minute' level >>>>> >>>>> [>---] 0% < 1 sec/< 1 sec 0 channels >>>>> [===>] 11% < 1 sec/< 1 sec 1 channels >>>>> [==>-] 22% < 1 sec/< 1 sec 2 channels >>>>> [=>--] 33% < 1 sec/< 1 sec 3 channels >>>>> [>---] 44% < 1 sec/< 1 sec 4 channels >>>>> In AbstractMySQLDriver.php line 106: >>>>> >>>>> An exception occurred while executing 'REPLACE INTO aggregate >>>>> (channel_id, type, timestamp, value, count) SELECT channel_ >>>>> id, ? AS type, MAX(agg.timestamp) AS timestamp, COALESCE( >>>>> SUM(agg.val_by_time) / (MAX(agg.timestamp) - MIN(agg.prev_times >>>>> tamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS count FROM ( >>>>> SELECT channel_id, timestamp, value, value * (timestam >>>>> p - @prev_time
Re: [vz-users] aggregate error minute level
Hallo Andreas. Der Fehler ist wieder gekommen. Log File und Dump liegen auf: https://nextcloud.service-uplink.de/s/9ddDJJqSPL9XxEP Grüße Am Do., 4. Juli 2019 um 10:15 Uhr schrieb Andreas Götz : > Kein Grund für eine Entschuldigung- Du hast das Problem doch perfekt > gelöst! > > Viele Grüße, > Andreas > > Am 04.07.2019 um 10:03 schrieb Christian S : > > Ist notiert und sorry nochmal :( > > Am Do., 4. Juli 2019 um 10:01 Uhr schrieb Andreas Götz >: > >> Bitte schick mir direkt -v und dump wenn es wieder passiert. Das kam >> jetzt 2x vor- irgendwo scheint der Wurm drin zu sein, mir fehlen aber >> ausreichend Informationen den zu beseitigen. >> >> Viele Grüße, >> Andreas >> >> Am 04.07.2019 um 09:58 schrieb Christian S : >> >> Danke Andreas für deine schnelle Antwort. >> >> Ich war leider schon zu schnell und hab mal in der Zwischenzeit gelesen >> welche commandos "aggregate" noch so bietet und ein "php /var/www/ >> volkszaehler.org/bin/aggregate rebuild" hat scheinbar das Problem >> beseitigt. >> >> Die Datenbank ist eine "mysql" Datenbank. Wenn du den dump aber noch >> immer brauchst lass ich dir den gerne zukommen. >> Auf jeden Fall werd ich mir das mit -v merken und das nächste mal etwas >> langsamer machen. >> >> Grüße >> >> >> >> Am Do., 4. Juli 2019 um 08:49 Uhr schrieb Andreas Götz > >: >> >>> Kannst Du das Kommando bitte nochmal mit -v ausführen damit ich den >>> Verursacher der Fehlermeldung sehr? >>> >>> Wäre es evtl möglich mir einen Dump Deiner DB zukommen zu lassen? Was >>> für eine DB ist das? >>> >>> Viele Grüße, >>> Andreas >>> >>> Am 04.07.2019 um 08:25 schrieb Christian S : >>> >>> >>> Hallo. >>> >>> Seit Tagen bekomme ich beim Ausführen von "aggregate" immer einen Fehler >>> (nur auf dem Level "minute"). >>> In den Log Files hätte ich jetzt nichts gefunden. Unten der Fehler im >>> Detail aber so richtig schlau werde ich nicht daraus. >>> >>> Grüße >>> >>> root@service-uplink:/home/nas# php /var/www/ >>> volkszaehler.org/bin/aggregate run -m delta -l minute >>> Performing 'delta' aggregation on 'minute' level >>> >>> [>---] 0% < 1 sec/< 1 sec 0 channels >>> [===>] 11% < 1 sec/< 1 sec 1 channels >>> [==>-] 22% < 1 sec/< 1 sec 2 channels >>> [=>--] 33% < 1 sec/< 1 sec 3 channels >>> [>---] 44% < 1 sec/< 1 sec 4 channels >>> In AbstractMySQLDriver.php line 106: >>> >>> An exception occurred while executing 'REPLACE INTO aggregate >>> (channel_id, type, timestamp, value, count) SELECT channel_ >>> id, ? AS type, MAX(agg.timestamp) AS timestamp, COALESCE( >>> SUM(agg.val_by_time) / (MAX(agg.timestamp) - MIN(agg.prev_times >>> tamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS count FROM ( >>> SELECT channel_id, timestamp, value, value * (timestam >>> p - @prev_timestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS >>> prev_timestamp, @prev_timestamp := timestamp FROM da >>> ta CROSS JOIN (SELECT @prev_timestamp := >>> UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d >>> %H:%i:00" >>> ), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND >>> aggregate.channel_id = ?) AS vars WHERE channel_id = ? AN >>> D timestamp >= IFNULL((SELECT >>> UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d >>> %H:%i:00"), INTERVAL >>>1 minute)) * 1000 FROM aggregate WHERE type = ? AND >>> aggregate.channel_id = ? ), 0) AND timestamp < UNIX_TIMESTAMP(DATE_F >>> ORMAT(NOW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY >>> channel_id, YEAR(FROM_UNIXTIME(timestamp/1000)), DAYOFYEAR(FR >>> OM_UNIXTIME(timestamp/1000)), HOUR(FROM_UNIXTIME(timestamp/1000)), >>> MINUTE(FROM_UNIXTIME(timestamp/1000))' with params [1, >>>1, "19", "19", 1, "19"]: >>> >>> SQLSTATE[22012]: Division by zero: 1365 Division by 0 >>> >>> >>> In PDOStatement.php line 119: >>> >>> SQLSTATE[22012]: Division by zero: 1365 Division by 0 >>> >>> >>> In PDOStatement.php line 117: >>> >>> SQLSTATE[22012]: Division by zero: 1365 Division by 0 >>> >>> >>> run [-l|--level LEVEL] [-m|--mode MODE] [-p|--periods PERIODS] >>> [-v|--verbose] [--] [...] >>> >>>
Re: [vz-users] aggregate error minute level
Ist notiert und sorry nochmal :( Am Do., 4. Juli 2019 um 10:01 Uhr schrieb Andreas Götz : > Bitte schick mir direkt -v und dump wenn es wieder passiert. Das kam jetzt > 2x vor- irgendwo scheint der Wurm drin zu sein, mir fehlen aber ausreichend > Informationen den zu beseitigen. > > Viele Grüße, > Andreas > > Am 04.07.2019 um 09:58 schrieb Christian S : > > Danke Andreas für deine schnelle Antwort. > > Ich war leider schon zu schnell und hab mal in der Zwischenzeit gelesen > welche commandos "aggregate" noch so bietet und ein "php /var/www/ > volkszaehler.org/bin/aggregate rebuild" hat scheinbar das Problem > beseitigt. > > Die Datenbank ist eine "mysql" Datenbank. Wenn du den dump aber noch immer > brauchst lass ich dir den gerne zukommen. > Auf jeden Fall werd ich mir das mit -v merken und das nächste mal etwas > langsamer machen. > > Grüße > > > > Am Do., 4. Juli 2019 um 08:49 Uhr schrieb Andreas Götz >: > >> Kannst Du das Kommando bitte nochmal mit -v ausführen damit ich den >> Verursacher der Fehlermeldung sehr? >> >> Wäre es evtl möglich mir einen Dump Deiner DB zukommen zu lassen? Was für >> eine DB ist das? >> >> Viele Grüße, >> Andreas >> >> Am 04.07.2019 um 08:25 schrieb Christian S : >> >> >> Hallo. >> >> Seit Tagen bekomme ich beim Ausführen von "aggregate" immer einen Fehler >> (nur auf dem Level "minute"). >> In den Log Files hätte ich jetzt nichts gefunden. Unten der Fehler im >> Detail aber so richtig schlau werde ich nicht daraus. >> >> Grüße >> >> root@service-uplink:/home/nas# php /var/www/ >> volkszaehler.org/bin/aggregate run -m delta -l minute >> Performing 'delta' aggregation on 'minute' level >> >> [>---] 0% < 1 sec/< 1 sec 0 channels >> [===>] 11% < 1 sec/< 1 sec 1 channels >> [==>-] 22% < 1 sec/< 1 sec 2 channels >> [=>--] 33% < 1 sec/< 1 sec 3 channels >> [>---] 44% < 1 sec/< 1 sec 4 channels >> In AbstractMySQLDriver.php line 106: >> >> An exception occurred while executing 'REPLACE INTO aggregate >> (channel_id, type, timestamp, value, count) SELECT channel_ >> id, ? AS type, MAX(agg.timestamp) AS timestamp, COALESCE( >> SUM(agg.val_by_time) / (MAX(agg.timestamp) - MIN(agg.prev_times >> tamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS count FROM ( >> SELECT channel_id, timestamp, value, value * (timestam >> p - @prev_timestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS >> prev_timestamp, @prev_timestamp := timestamp FROM da >> ta CROSS JOIN (SELECT @prev_timestamp := >> UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d >> %H:%i:00" >> ), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND >> aggregate.channel_id = ?) AS vars WHERE channel_id = ? AN >> D timestamp >= IFNULL((SELECT >> UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d >> %H:%i:00"), INTERVAL >>1 minute)) * 1000 FROM aggregate WHERE type = ? AND >> aggregate.channel_id = ? ), 0) AND timestamp < UNIX_TIMESTAMP(DATE_F >> ORMAT(NOW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY channel_id, >> YEAR(FROM_UNIXTIME(timestamp/1000)), DAYOFYEAR(FR >> OM_UNIXTIME(timestamp/1000)), HOUR(FROM_UNIXTIME(timestamp/1000)), >> MINUTE(FROM_UNIXTIME(timestamp/1000))' with params [1, >>1, "19", "19", 1, "19"]: >> >> SQLSTATE[22012]: Division by zero: 1365 Division by 0 >> >> >> In PDOStatement.php line 119: >> >> SQLSTATE[22012]: Division by zero: 1365 Division by 0 >> >> >> In PDOStatement.php line 117: >> >> SQLSTATE[22012]: Division by zero: 1365 Division by 0 >> >> >> run [-l|--level LEVEL] [-m|--mode MODE] [-p|--periods PERIODS] >> [-v|--verbose] [--] [...] >> >>
Re: [vz-users] aggregate error minute level
Danke Andreas für deine schnelle Antwort. Ich war leider schon zu schnell und hab mal in der Zwischenzeit gelesen welche commandos "aggregate" noch so bietet und ein "php /var/www/ volkszaehler.org/bin/aggregate rebuild" hat scheinbar das Problem beseitigt. Die Datenbank ist eine "mysql" Datenbank. Wenn du den dump aber noch immer brauchst lass ich dir den gerne zukommen. Auf jeden Fall werd ich mir das mit -v merken und das nächste mal etwas langsamer machen. Grüße Am Do., 4. Juli 2019 um 08:49 Uhr schrieb Andreas Götz : > Kannst Du das Kommando bitte nochmal mit -v ausführen damit ich den > Verursacher der Fehlermeldung sehr? > > Wäre es evtl möglich mir einen Dump Deiner DB zukommen zu lassen? Was für > eine DB ist das? > > Viele Grüße, > Andreas > > Am 04.07.2019 um 08:25 schrieb Christian S : > > > Hallo. > > Seit Tagen bekomme ich beim Ausführen von "aggregate" immer einen Fehler > (nur auf dem Level "minute"). > In den Log Files hätte ich jetzt nichts gefunden. Unten der Fehler im > Detail aber so richtig schlau werde ich nicht daraus. > > Grüße > > root@service-uplink:/home/nas# php /var/www/volkszaehler.org/bin/aggregate > run -m delta -l minute > Performing 'delta' aggregation on 'minute' level > > [>---] 0% < 1 sec/< 1 sec 0 channels > [===>] 11% < 1 sec/< 1 sec 1 channels > [==>-] 22% < 1 sec/< 1 sec 2 channels > [=>--] 33% < 1 sec/< 1 sec 3 channels > [>---] 44% < 1 sec/< 1 sec 4 channels > In AbstractMySQLDriver.php line 106: > > An exception occurred while executing 'REPLACE INTO aggregate > (channel_id, type, timestamp, value, count) SELECT channel_ > id, ? AS type, MAX(agg.timestamp) AS timestamp, COALESCE( > SUM(agg.val_by_time) / (MAX(agg.timestamp) - MIN(agg.prev_times > tamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS count FROM ( > SELECT channel_id, timestamp, value, value * (timestam > p - @prev_timestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS > prev_timestamp, @prev_timestamp := timestamp FROM da > ta CROSS JOIN (SELECT @prev_timestamp := > UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d > %H:%i:00" > ), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND > aggregate.channel_id = ?) AS vars WHERE channel_id = ? AN > D timestamp >= IFNULL((SELECT > UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d > %H:%i:00"), INTERVAL >1 minute)) * 1000 FROM aggregate WHERE type = ? AND > aggregate.channel_id = ? ), 0) AND timestamp < UNIX_TIMESTAMP(DATE_F > ORMAT(NOW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY channel_id, > YEAR(FROM_UNIXTIME(timestamp/1000)), DAYOFYEAR(FR > OM_UNIXTIME(timestamp/1000)), HOUR(FROM_UNIXTIME(timestamp/1000)), > MINUTE(FROM_UNIXTIME(timestamp/1000))' with params [1, >1, "19", "19", 1, "19"]: > > SQLSTATE[22012]: Division by zero: 1365 Division by 0 > > > In PDOStatement.php line 119: > > SQLSTATE[22012]: Division by zero: 1365 Division by 0 > > > In PDOStatement.php line 117: > > SQLSTATE[22012]: Division by zero: 1365 Division by 0 > > > run [-l|--level LEVEL] [-m|--mode MODE] [-p|--periods PERIODS] > [-v|--verbose] [--] [...] > >
[vz-users] aggregate error minute level
Hallo. Seit Tagen bekomme ich beim Ausführen von "aggregate" immer einen Fehler (nur auf dem Level "minute"). In den Log Files hätte ich jetzt nichts gefunden. Unten der Fehler im Detail aber so richtig schlau werde ich nicht daraus. Grüße root@service-uplink:/home/nas# php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute Performing 'delta' aggregation on 'minute' level [>---] 0% < 1 sec/< 1 sec 0 channels [===>] 11% < 1 sec/< 1 sec 1 channels [==>-] 22% < 1 sec/< 1 sec 2 channels [=>--] 33% < 1 sec/< 1 sec 3 channels [>---] 44% < 1 sec/< 1 sec 4 channels In AbstractMySQLDriver.php line 106: An exception occurred while executing 'REPLACE INTO aggregate (channel_id, type, timestamp, value, count) SELECT channel_ id, ? AS type, MAX(agg.timestamp) AS timestamp, COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - MIN(agg.prev_times tamp)), AVG(agg.value)) AS value, COUNT(agg.value) AS count FROM ( SELECT channel_id, timestamp, value, value * (timestam p - @prev_timestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS prev_timestamp, @prev_timestamp := timestamp FROM da ta CROSS JOIN (SELECT @prev_timestamp := UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d %H:%i:00" ), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND aggregate.channel_id = ?) AS vars WHERE channel_id = ? AN D timestamp >= IFNULL((SELECT UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, "%Y-%m-%d %H:%i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type = ? AND aggregate.channel_id = ? ), 0) AND timestamp < UNIX_TIMESTAMP(DATE_F ORMAT(NOW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY channel_id, YEAR(FROM_UNIXTIME(timestamp/1000)), DAYOFYEAR(FR OM_UNIXTIME(timestamp/1000)), HOUR(FROM_UNIXTIME(timestamp/1000)), MINUTE(FROM_UNIXTIME(timestamp/1000))' with params [1, 1, "19", "19", 1, "19"]: SQLSTATE[22012]: Division by zero: 1365 Division by 0 In PDOStatement.php line 119: SQLSTATE[22012]: Division by zero: 1365 Division by 0 In PDOStatement.php line 117: SQLSTATE[22012]: Division by zero: 1365 Division by 0 run [-l|--level LEVEL] [-m|--mode MODE] [-p|--periods PERIODS] [-v|--verbose] [--] [...]
Re: [vz-users] Wiki: Artikel komplett überschrieben
Hallo. Was hat es eigentlich mit den Asci Zeichen aufsich bei den Bildern? [image: image.png] Grüße Am Sa., 22. Juni 2019 um 13:08 Uhr schrieb Rupert Schöttler < rupert.schoett...@gmx.de>: > Am 22.06.19 um 13:05 schrieb Justin Otherguy: > > > > Das ist ein klarer Fall von Spam; das hatten wir lange nicht mehr. > > Ich habe die Seite im Zustand vor der ersten Änderung wiederhergestellt > und den Account gelöscht. > > Danke, Justin! :-) > > > Schönen Tag weiterhin > > Rupert > > >
Re: [vz-users] Traffic der Fritz Box im VZ
Guten Morgen. Aus meiner Sicht: Wie alle anderen Daten über die middleware schicken. Da das Tool selbst nicht open source ist... wirst du wohl den Ersteller kontaktieren müssen. Grüße Am Di., 2. Apr. 2019 um 07:24 Uhr schrieb : > Guten Morgen, > > ich würde gern den Traffic der Fritzbox mitschreiben und darstellen. > Es gibt ein freies Tool http://www.bawe.eu/cms/Projekte.html aber eine > Integration im Volkszähler wäre natürlich cool. > > Hat jemand eine Idee wie das gehen kann? > > Besten Dank und einen schönen Start in den Tag. > > Grüße > Sven > >
Re: [vz-users] Volkszähler 2.0 - Neue Features
Hallo. Hab gestern das Update gemacht und läuft perfekt. Danke! Sieht wirklich gut aus und auch mein Liebling sind die Balkendiagramme :) Grüße, Christian Am Do., 14. März 2019 um 09:56 Uhr schrieb Andreas Goetz : > Hallo Zusammen, > > in den letzten Tagen habe ich das Mistwetter genutzt um einige schon lange > fällige Anpassungen in den Master Branch zu bringen: > > *Virtuelle Kanäle* > > Funktionieren seit langer Zeit. UI zur Erstellung ist nicht perfekt (u.a. > keine Dropdowns zur Auswahl der Eingabekanäle) und die Darstellung ist > abhängig der Auflösung (workaround: virtuelle Kanäle persistieren und > aggregieren; könnte man separat überlegen ist aber momentan zeitbedingt > keine Prio). > > Virtuelle Kanäle schließen “ad-hoc” Abfragen mit Hilfe des /query > Kontextes ein. > > *Verbrauchsanzeige* > > Mein persönlicher Favorit: Balkendiagramme mit Stunden/Tagesverbräuchen. > Hat manchmal Probleme mit Timestamps am Darstellungsrand, lässt sich aber > sicher lösen wenn das Problem eingegrenzt ist. Fehler bitte melden. > > *Prognose* > > Einfache Verbrauchsprognose auf Basis Vergleichszeitraum (Vortag, Vormonat > oder letztes Jahr). Sehr nützlich für PV-Erzeugung oder > Strom/Öl/Gasverbrauch. > > > > > *ACHTUNG: PHP 7.1 erforderlichDie neue Version benötigt zwingend php ^7.1 > (wie natürlich auch ein composer update). php 7.1 oder besser 7.3 kann > aktuell bei Raspbian nur aus buster nachinstalliert werden welches noch > nicht released ist. Hier ist ein wenig Handarbeit mittels der apt > preferences notwendig.* > > *ingress* > > lohnt auch weiter einen Test wenn es darum geht Daten aus verschiedenen > Quellen in VZ zu bringen. Aktuell neu ist Aggregation wie sie auch vzlogger > beherrscht. > > *Sonstiges* > > - InfluxDB Export (in dbcopy implementiert und für ingress als PoC fertig) > - Grafana Dashboard Export (PoC fertig) > > Viele Grüße, > Andreas > > >
Re: [vz-users] DHT11 - Scriptdatei
Hallo Rupert. Funktion ist eines und das es nicht funktioniert meinte ich auch nicht. Aber wenn man ein Projekt plant hat man ein Konzept. Und das Konzept vom Volkszähler ist nunmal das man die Daten via middleware abliefert. Würden wir jetzt lauter Tools ins Wiki stellen die direkt die Daten via SQL abliefern.. wäre ein wenig Chaos oder? Grüße I Am Sa., 26. Jan. 2019 um 13:34 Uhr schrieb Rupert Schöttler < rupert.schoett...@gmx.de>: > Hallo Christian, > > Am 26.01.19 um 13:29 schrieb Christian S: > > Sollte man nicht eher die Daten abliefern via "middleware"? > > > M.E. funktionieren beide Wege gleich gut und sind daher > gleichberechtigt. Klar, wer direkt in die DB schreibt, muss wissen, was > er/sie tut. Die Middleware fängt viele Fehler ab. > > Auch das wäre Wiki-Einträge wert: Beispiel-Skripte, wie man mit den > vielen verschiedenen Sprachen die DB oder die Middleware anspricht. > Bisher ist das weit verteilt. > > Viele Grüße > > Rupert > > >
Re: [vz-users] DHT11 - Scriptdatei
Hallo. Sollte man nicht eher die Daten abliefern via "middleware"? Grüße Am Sa., 26. Jan. 2019 um 13:23 Uhr schrieb Rupert Schöttler < rupert.schoett...@gmx.de>: > Hallo Peer, > > Am 26.01.19 um 01:51 schrieb Peer Janssen: > > Hier nochmal das Script als Datei (in der Mail eben waren die > > Zeilenumbrüche unschön). > > > > Außerdem als Bonus noch ein Converter-Script für die alten Daten (als > > Beispiel), und ein Screenshot. > > > Danke, dass Du Deine Skript-Entwicklung hier teilst! Ich bin kein > Python-Kenner, aber sie sehen für mich sehr elegant und kompakt aus und > sollten daher meiner Meinung nach daher ins Wiki eingehen. Magst Du Dich > dort registrieren? Justin müsste Dir dann noch Schreibrecht geben, und > Du könntest z.B. unter Hardware -> Sensors einen DHT-Eintrag anlegen. > Von DHT22 hattest Du vorher ja "abgekupfert" :-) > > Nur eine Anmerkung: Sollte die Datenbank-Verbindung, die mit > MySQLdb.connect geöffnet wird, nicht zum Schluss auch geschlossen > werden? Ich hab' ja keine Ahnung, wie Python am Ende eines Skripts > tickt, aber wenn die Verbindung offen bleibt und jede Minute eine neue > geöffnet wird, könnte es irgendwann Probleme geben... > > Viele Grüße > > Rupert > > >
