Re: [vz-dev] Entitydefinition: Wo sind die Einheiten?
Wieder was gelernt- das reicht tatsächlich, also nix neues benötigt, danke! 2013/9/27 Thorben Thuermer r...@constancy.org On Tue, 24 Sep 2013 18:04:32 +0200 Andreas Goetz cpui...@gmail.com wrote: ich beschäftige mich jetzt seit einiger Zeit mit der Visualisierung von VZ-Daten (Stichwort VZmon App). Jetzt bin ich darüber gestolpert, dass wir zwar allerlei Präsentationsparameter (steps, color) in den Entities speicher, bzgl. der physischen Eigenschaften aber ziemlich blank sind, u.a. fehlen hier ganz banal die Einheiten. soweit ich das sehe, stehen die einheiten hier (als unit): https://github.com/volkszaehler/volkszaehler.org/blob/master/lib/Definition/EntityDefinition.json das sind dann wohl die statischen eigenschaften des entity-typs, und in der datenbank stehen nur die speziellen der jeweiligen instanz? Da ich mich mit den Doctrine Entity Definitionen nicht gut genug auskenne um dafür eine Erweiterung zu bauen bin ich auf Hilfe angewiesen. Gibts dafür Interesse/ Unterstützung? ansonsten auch keine weitere erfahrung damit. vg Andreas - Thorben
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
Hallo Torben, 2013/9/27 Thorben Thuermer r...@constancy.org On Tue, 24 Sep 2013 14:35:02 +0200 Patrik Karisch patrik.kari...@gmail.com wrote: Bis jetzt hat sich weder Justin noch Steffen dazu geäußert. damit da mal was zu gesagt wird: justin ist der initiator des projekts, eine antwort von ihm fehlt hier irgendwie, er sagte mir er hat leider gerade keine zeit dafuer/anderes zu tun. steffen ist schon laenger nichtmehr gross im projekt aktiv. Am 24. September 2013 14:07 schrieb Andreas Goetz cpui...@gmail.com: Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas einbringen kann und das sich vielleicht generell etwas interaktionsfreudiger gitb als die aktuelle Struktur:... wenn jemand meint, dass wir mehr brauchen und dass er einer davon ist, wuerde ich vorschlagen justin zu kontaktieren. Dh. außerhalb dieser Liste per Mail? - schnellere Bearbeitung von requests ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet werden/sein sollten. Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne commit, sondern auch ohne Test- weil's einfach niemanden interessiert. Vielleicht könnte ein -dev Zweig helfen solche Probleme wie den eingeführten Fehler abzumildern. ersichtlich ist worum es ueberhaupt geht (commit messages und kommentare helfen!), bin ich auch erstmal skeptisch. wobei aber wohl auch momentan ein allgemeines weiterkommen wichiger ist, als der eine oder andere neue bug. (ein schoenes beispiel war, wie justin zuletzt relativ hektisch Du meinst nach 6 Wochen ist Hektik aufgekommen ;? diesen germerged hatte: https://github.com/volkszaehler/volkszaehler.org/pull/47 und da prompt ein bug drin war, der die api unbrauchbar gemacht hat http://www.mail-archive.com/volkszaehler-dev@lists.volkszaehler.org/msg01921.html und der bei einer kurzen review (justin ist kein programmierer), oder einem test woanders als beim autor, aufgefallen waehre. Korrekt- hat aber keine gemacht :/ (was aber dann ja auch schnell behoben war!) https://github.com/volkszaehler/volkszaehler.org/pull/49 ) So isses. Und um hier aktiv etwas beizutragen: ich habe immer noch einen Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin- die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen... und das problem, dass die aenderungen schnell unuebersichtlich werden, und man sich schwerer tut grosse pull requests zu mergen, als kleinere fixes fuer einfache probleme. Ich bin auch kein Git Experte, hatte aber das Problem dass Github alle meine Commits in den schon bestehenden PR gepackt hat- kleiner ging erstmal nicht... (siehe den herrn hirsch, der herumlurkt und kleine aber wichtige commits blitzartig merged ;) ) ich denke es waehre da sinnvoll aenderungen vorher kurz zu diskutieren, zB hier (oder in den github issues?) und zu einem konsens zu kommen. Mehr als die Sachen per Mail hier anzupreisen kann ich wohl nicht tun. Oder doch? es gab es ja zB den thread Feedback benötigt: vzlogger / aggregation / random meter / sml-pull / s0-meter ( http://article.gmane.org/gmane.network.volkszaehler.devel/1572 ) der leider recht schleppend verlief. die letzte meldung von justin dazu war... http://volkszaehler.org/pipermail/volkszaehler-dev/2013-August/003005.html On Wed, 28 Aug 2013 23:51:03 +0200 Justin Otherguy jus...@justinotherguy.org wrote: korrekt (leider). Die Patches lassen sich nicht g'schwind(TM) mergen. Scheitert an magischen git-Kräften (und der alternativ benötigten Zeit). Falls mir Jemand beispringen möchte: das ist eine gute Gelegenheit! ;-) darauf hatte sich niemand gemeldet... ich werde mir das sonst mal anschauen. - Nutzung der github Issues habe anscheinend nicht die rechte das einzustellen... werde justin mal anhauen, wenn er nicht selber mitliest. - Thorben Logger ist leider nicht mein Thema :( vg Andreas
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
On Fri, 27 Sep 2013 08:57:39 +0200 Andreas Goetz cpui...@gmail.com wrote: Hallo Torben, +h 2013/9/27 Thorben Thuermer r...@constancy.org wenn jemand meint, dass wir mehr brauchen und dass er einer davon ist, wuerde ich vorschlagen justin zu kontaktieren. Dh. außerhalb dieser Liste per Mail? z.B. - schnellere Bearbeitung von requests ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet werden/sein sollten. Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne commit, sondern auch ohne Test- weil's einfach niemanden interessiert. das ist aber kein problem des maintainers, sondern der community. da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei mir zB., alles selbst zu testen. Vielleicht könnte ein -dev Zweig helfen solche Probleme wie den eingeführten Fehler abzumildern. macht den prozess aber noch traeger/langwieriger, wenn dann noch zwei merges noetig sind, user-fork - dev-fork - master... siehe auch naechster punkt: wobei aber wohl auch momentan ein allgemeines weiterkommen wichiger ist, als der eine oder andere neue bug. (ein schoenes beispiel war, wie justin zuletzt relativ hektisch diesen germerged hatte: https://github.com/volkszaehler/volkszaehler.org/pull/47 und da prompt ein bug drin war, der die api unbrauchbar gemacht hat Du meinst nach 6 Wochen ist Hektik aufgekommen ;? ja genau. er hatte wohl (soll er mich korrigieren wenn ich das falsch interpretiere) den relativ hektisch einfach ohne test gemerged, nachdem er solange rumlag, und nachgefragt wurde warum er nicht gemerged ist. http://www.mail-archive.com/volkszaehler-dev@lists.volkszaehler.org/msg01921.html und der bei einer kurzen review (justin ist kein programmierer), oder einem test woanders als beim autor, aufgefallen waehre. Korrekt- hat aber keine gemacht :/ wie gehabt, wir (bzw. wohl justin) sehen darin nicht die alleinige verantwortung des maintainers, und haben auch nicht die resourcen (zeit) dafuer. Und um hier aktiv etwas beizutragen: ich habe immer noch einen Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin- die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen... ich wollte schonmal dazu sagen: was genau hindert dich daran, den test-code zu commiten und einen pull-request zu stellen? das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein (wenig?) vorhandener code veraendert wird. und das problem, dass die aenderungen schnell unuebersichtlich werden, und man sich schwerer tut grosse pull requests zu mergen, als kleinere fixes fuer einfache probleme. Ich bin auch kein Git Experte, hatte aber das Problem dass Github alle meine Commits in den schon bestehenden PR gepackt hat- kleiner ging erstmal nicht... sehe ich auch so, ist aber wohl auch eine eigenschaft von git? (wobei ich gestern schonmal rausgefunden habe, wie man einzelne commits mergen kann, auch wenn's etwas umstaendlich erscheint.) ich denke es waehre da sinnvoll aenderungen vorher kurz zu diskutieren, zB hier (oder in den github issues?) und zu einem konsens zu kommen. Mehr als die Sachen per Mail hier anzupreisen kann ich wohl nicht tun. Oder doch? denke nicht, siehe community-problem. siehe auch der naechste punkt. (auch sprach ich von pull-requests, die manchmal reinkommen ohne dass es hier einen thread dazu gibt, die liegen dann noch laenger rum ;) ) es gab es ja zB den thread Feedback benötigt: vzlogger / aggregation / random meter / sml-pull / s0-meter ( http://article.gmane.org/gmane.network.volkszaehler.devel/1572 ) der leider recht schleppend verlief. die letzte meldung von justin dazu war... http://volkszaehler.org/pipermail/volkszaehler-dev/2013-August/003005.html On Wed, 28 Aug 2013 23:51:03 +0200 Justin Otherguy jus...@justinotherguy.org wrote: korrekt (leider). Die Patches lassen sich nicht g'schwind(TM) mergen. Scheitert an magischen git-Kräften (und der alternativ benötigten Zeit). Falls mir Jemand beispringen möchte: das ist eine gute Gelegenheit! ;-) darauf hatte sich niemand gemeldet... ich werde mir das sonst mal anschauen. Logger ist leider nicht mein Thema :( wobei's da eher um das git-thema geht, (bei dem pull-request zeigt github nicht an, dass der automatisch merge-bar sei, sonst haette justin schon laenger auf den button geklickt.) vg Andreas - Thorben
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
Hallo, Am 27.09.2013 13:52, schrieb Thorben Thuermer: wie gehabt, wir (bzw. wohl justin) sehen darin nicht die alleinige verantwortung des maintainers, und haben auch nicht die resourcen (zeit) dafuer. Kann es ja auch nicht sein - den Core mag man testen können, beim Drumherum gibt es stellen, die nur sehr wenige Leute nutzen/kennen - wie soll das jemand, der weder die Geräte noch das Wissen hat, testen? Da müssen die passenden Tests - oder wenn es keinen Tester gibt eben dann nachträglich Bug-Reports - von Außen kommen. Ich bin auch kein Git Experte, hatte aber das Problem dass Github alle meine Commits in den schon bestehenden PR gepackt hat- kleiner ging erstmal nicht... sehe ich auch so, ist aber wohl auch eine eigenschaft von git? Richtig - am besten eine Branch erzeugen und daraus den Pull-Request commiten - dann kann man am Original weiterarbeiten ohne den Request zu verändern. Generell sollte man seine Änderungen immer in Branches halten, dann bleibt das Original auf dem Stand des offiziellen Repos und darauf aufbauende Pull-Requests lassen sich wesentlich einfacher mergen. -- Mit freundlichen Grüßen || Sincerely yours Florian Knodt ·· Im Teich 11 ·· 56648 Saffig www.adlerweb.info · www.56648.de · @adlerweb signature.asc Description: OpenPGP digital signature
Re: [vz-dev] vzlogger, pull-sequenz fuer Landis+Gir (ZMD120APTCS G03)
Datum: Freitag, 27. September 2013 08:03:16 On Thu, 26 Sep 2013 22:42:22 +0200 Karlheinz karlheinz...@gmx.de wrote: wie bekomme ich meinen Landis+Gir Zähler (ZMD120APTCS G03) dazu, vzlogger zu antworten? Ich benutze den IR-Schreib-Lesekopf von Udo. Die config sieht ok aus. (wenn deine Zähler auf 7E1 300 Baud und die Sequenz /?!CRLF reagiert ) Auszug aus vzlogger.conf: --protocol : d0, --parity : 7E1, ---pullseq : 2f3f210d0a, // HEX Darstellung der Pullsequenz Bislang kommt immer folgendes bei vzlogger -f: [Sep 26 22:05:00][d0] sending pullsequenz send (len:22 is:22). [Sep 26 22:05:00][d0] Something unexpected happened: read:336! das ist eine leider arg nichtssagende meldung, die bedeutet, dass vzlogger ein byte von der schnittstelle gelesen hat, mit dem er nichts anfangen konnte. (ich hatte da schon mehrmals nachgebessert, ist wohl aber irgendwie wieder rausgeflogen.) ich vermute aenderungen sind nicht nur beim senden der pull-sequenz, sondern auch beim parsen der antwort noetig. Im Beitrag http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/itron_ace3000_type_260 habe ich das Shellscript gefunden und gekürzt: # Init tty stty -F /dev/ttyAMA0 1:4:da7:a30:3:1c:7f:15:4:10:0:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 ( sleep 1 ; echo -e \x2f\x3f\x21\x0d\x0a /dev/ttyUSB0 ) Damit kommt zumindest schon eine Antwort: /?! /LGZ52ZMD120APt.G03 Erst mit einer weiteren Sequenz liefert der Zähler seine Daten ab: ( sleep 1 ; echo -e \x2F\x3F\x21\x0D\x0A\x00\x00\x00\x00\x00\x00\x00\x06\x30\x30\x30\x0D\x0A /dev/ttyAMA0 ) # bedeutet:/?! CR LF NUL NUL NUL NUL NUL NUL ACK 0 0 0 CR LF #das geht auch: ( sleep 1 ; echo -e \x2f\x41\x43\x45\x30\x5c\x33\x6b\x32\x36\x30\x56\x30\x31\x2e\x31\x38 /dev/ttyAMA0 ) # bedeutet: /ACE0\3k260V01.18 Jetzt erhalte ich die Zählerwerte: [...] *1. Was initialisiert stty im Gegensatz zum vzlogger anders? Wenn das geklärt ist, sollte zumindest kein Fehler 336 mehr kommen.** nachdem vzlogger lief mit stty die einstellungen auslesen und vergleichen. aus man stty: -a, --all print all current settings in human-readable form -g, --save print all current settings in a stty-readable form (so entstand auch der lange hex-string im stty-aufruf) die Ausgabe von stty -a in einer parallelen Session, während und nachdem vzlogger lief ist identisch. **2. Könnte man einen weiteren Parameter, der nach der pullsequenz eine zweite Sequenz (acksequenz) sendet, einbauen?** dass wir das pullsequez feature ueberhaupt haben ist schon sehr neu (credits an peter evertz!) leider scheint es dann viele zaehler mit recht speziellen anforderungen zu geben, wie deinen zB.. sowohl bei den request-sequenzen, als auch anforderungen an das timing. das alles allgemein und konfigurierbar umzusetzen wird wohl so kurzfristig nichts, insbesondere da das testen schwer ist, ohne die hardware (zaehler) vor ort zu haben. Wenn jemand helfen möchte, gebe ich gern ssh - Zugangsdaten bekannt. ich wuerde als einfacheren ansatz erstmal die alte methode vorschlagen, waehrend vzlogger laeuft die sequenzen mit einem script zu senden. (oder alternativ komplett ein zaehler-spezifisches script statt vzlogger zu verwenden.) während vzlogger -f alle 5 Sekunden läuft habe ich /dev/ttyAMA0 ausgelesen: #!/bin/bash while read -t8 line do echo $line done /dev/ttyAMA0 Dabei werden alle Zählerstände angezeigt! Dann liegt es wohl eher am parsen der Antwort - wie du vermutet hast. Manchmal schnappt vzlogger irgend etwas auf: Read package with 0 tuples (vendor=1:51][m!r1], baudrate=, identification=2) Kann es sein, dass vzlogger nicht lange genug auf eine Antwort wartet? Gibt es dazu noch vzlogger-Parameter? oder aber du nimmst dir den C-code von vzlogger, und versuchst zB erstmal eine version hinzubekommen, die mit deinem zaehler funktioniert, so dass man das spaeter vlt. integrieren kann. Meine C-Kenntnisse sind genau so gut wie PHP - das wird also schwierig :-( Viele Grüße Karlheinz - Thorben Karlheinz
Re: [vz-dev] vzlogger, pull-sequenz fuer Landis+Gir (ZMD120APTCS G03)
On Fri, 27 Sep 2013 22:31:29 +0200 Karlheinz karlheinz...@gmx.de wrote: On Thu, 26 Sep 2013 22:42:22 +0200 Karlheinz karlheinz...@gmx.de wrote: wie bekomme ich meinen Landis+Gir Zähler (ZMD120APTCS G03) dazu, vzlogger zu antworten? Ich benutze den IR-Schreib-Lesekopf von Udo. Die config sieht ok aus. (wenn deine Zähler auf 7E1 300 Baud und die Sequenz /?!CRLF reagiert ) Auszug aus vzlogger.conf: --protocol : d0, --parity : 7E1, ---pullseq : 2f3f210d0a, // HEX Darstellung der Pullsequenz Bislang kommt immer folgendes bei vzlogger -f: [Sep 26 22:05:00][d0] sending pullsequenz send (len:22 is:22). [Sep 26 22:05:00][d0] Something unexpected happened: read:336! das ist eine leider arg nichtssagende meldung, die bedeutet, dass vzlogger ein byte von der schnittstelle gelesen hat, mit dem er nichts anfangen konnte. (ich hatte da schon mehrmals nachgebessert, ist wohl aber irgendwie wieder rausgeflogen.) ich vermute aenderungen sind nicht nur beim senden der pull-sequenz, sondern auch beim parsen der antwort noetig. [...] ich wuerde als einfacheren ansatz erstmal die alte methode vorschlagen, waehrend vzlogger laeuft die sequenzen mit einem script zu senden. (oder alternativ komplett ein zaehler-spezifisches script statt vzlogger zu verwenden.) während vzlogger -f alle 5 Sekunden läuft habe ich /dev/ttyAMA0 ausgelesen: das ist allerdings genau das gegenteil vom vorschlag. ;) Dabei werden alle Zählerstände angezeigt! Dann liegt es wohl eher am parsen der Antwort - wie du vermutet hast. Manchmal schnappt vzlogger irgend etwas auf: Read package with 0 tuples (vendor=1:51][m!r1], baudrate=, identification=2) Kann es sein, dass vzlogger nicht lange genug auf eine Antwort wartet? Gibt es dazu noch vzlogger-Parameter? der parser versteht einfach das format nicht. poste mal bitte einen binaeren dump (kein copypaste) der antwort, damit koennte dann jemand der zeit hat untersuchen, warum der parser die daten nicht versteht. oder aber du nimmst dir den C-code von vzlogger, und versuchst zB erstmal eine version hinzubekommen, die mit deinem zaehler funktioniert, so dass man das spaeter vlt. integrieren kann. Meine C-Kenntnisse sind genau so gut wie PHP - das wird also schwierig :-( - Thorben
