Keine regelmäßigen Power-Readings bei tapHome EASYPLUG

[A.Harrenberg]

Hi Krikan,

Wenn das Gerät V2 oder mehr kann, dann müsstest Du bitte mal die "supportetGet" der Class METER abrufen.
Das geht über einen RAW-Abruf (vorher verbose 5 anschalten)

Das Gerät hat Meter_V2 und gibt bei dem supported get folgendens zurück:

2015-05-16 08:51:04.299 ZWave ZWave_SW UNPARSED: METER 0432048105

04 Länge
32 Command Class
04 METER_SUPPORTED_REPORT
81 Data Byte 1
05 Data Byte 2

Data Byte 1: 81 = 10000001
bit 7 = 1 Meter Reset (supported)
bit 65 = reserverd
bit 43210 = 00001 Meter Type = 0x01 Electric meter

Data Byte 2: 05 = 00000101
bit 7654 = reservered
bit 3210 = 0101 Scale Supported, bit 0 -> kWh Accumulated, bit 2 -> W Instant

Das interpretiere ich jetzt mal so das ich mit einem entsprechenden METER_GET dann beide Werte abfragen kann. Dann habe ich jetzt ja mal was zu tun... Dann werde ich mir mal die beiden Befehle anlegen und dann mal schauen wie ich den Report geeignet parse, da werden doch schon eine Menge Informationen gesendet.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

so, wenn man dem Gerät jetzt bei get nicht nur 0x01 schickt sondern 0x0110 (so wie beim Philio_PAN04), dann bekommt man auch ein power Rückmeldung. Allerdings sieht der momentan Parse-Block für mich erst mal nach V1 aus. Die Watt-Angabe stimmt, aber bei V2 sollten noch mehr Informationen verfügbar sein (Delta-Time und Previous Meter Value). Das schaue ich mir später an.

Soweit schon mal so gut. Damit ist schon mal sichergestellt das man wenigsten den Werte pollen kann.

Nein, das Versionsproblem ist mehr oder weniger "unter dem Teppich gekehrt". Haeufig sind die Nachrichten unterschiedlich, so dass FHEM sie unterscheiden kann, wir sollten es aber ab sofort dokumentieren.

Allerdings bietet das Modul beim Vorhandensein einer Klasse die gets/sets unabhaengig von der Version an, was in manchen (mAn seltenen) Faellen falsch ist. Waere eine groessere Baustelle das "richtig" zu machen, und ich weiss noch nicht genau, wann das notwendig ist.

Ich habe mir die Formate für den METER_REPORT bei V1 und V2 nur kurz angeschaut, es gibt eine gewisse "Rückwärtskompatibilität", aber ich frage mich wie man beim Parsen gezielt auf eine Version reagieren könnte. Eine entsprechende Information gibt es meines Wissen nach nicht, wobei ich jetzt nicht weiss was sich so alles in dem $hash befindet, das ist für mich momentan noch eine Wundertüte...

Ich habe mir das Gerät jetzt erst mal unter deviceSpecial angelegt und werde dort mal damit rumspielen.

Gruß,
Andreas.

[krikan]

Der Philio PAN04 hat schon V3 und dort gibt es meiner Erinnerung nach Änderungen an der Skalierung, darum war das auch in device_specials gelandet.
Rückwärtskompatibilität der Versionen ist zumeist gegeben, aber man hat halt dann nicht alles.

Die Information zu den  Versionen der Classes wird bisher nicht in Fhem standardmäßig abgefragt und abgespeichert. Das musst Du manuell machen, wobei das dann erzeugte Reading nirgendwo durch Fhem automatisch berücksichtigt wird. Das ist reine User-Info. Im hash steckt dazu nichts. Allgemeines zum hash  findest Du hier: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Der_Hash_einer_Ger.C3.A4teinstanz

Fhem unterscheidet die Versionen der Classes manchmal an den Unterschieden der Nachrichtenlänge (bspw. SENSOR_BINARY), ignoriert die Unterschiede in den Classes durch entsprechende Regex und nutzt damit die Rückwärtskompatitbilität oder bietet Befehle neuerer Versionen immer an (WAKE_UP),...

Theoretisch ist eine Änderung auf andere (bessere?) Berücksichtung der Versionen kein Problem. Bei der Inklusion müssten für alle Classes die Version abgefragt werden und bspw an die jeweiligen Classes im entsprechende Attribut classes als Anhängsel (z.B. METER_3) abgespeichert werden, dann bei set/get/parse entsprechend der Versionen verarbeiten mit Rückfall auf V1. Nächster Schritt wäre dann bei den neueren Versionen über supportedGet die unterstützten Kommandos abzurufen und anzubieten Nur bei mir geht es nicht über die Theorie hinaus; Umsetzung in Code schaffe ich nicht. Den ersten Teil meines Gedankenganges habe ich probiert, bin aber gnadenlos gescheitert. Zudem wird dann in ZWave-Fhem alles deutlich komplizierter und das lastet auf der Schulter eines Anderen

Da stellt sich  mir grundsätzlich Frage, was soll alles eingebaut sein?. Für mich habe ich testhalber bspw. bei ZWDongle diverse Ergänzungen an den unterstützten Commands vorgenommen, die aber nicht als Patch zur Verfügung gestellt, da die Dinge eigentlich produktiv gar nicht notwendig sind. Die Ergänzungen dienen nur mir, um vielleicht einen tieferen Einblick zu bekommen (was leider nicht immer gelingt). Andere würde mit den Ergänzungen evtl. die Fülle der "unnötigen" Commands und Infos verwirren. Wen so was interessiert, der kann es notfalls auch per raw abrufen. Bei ZWave.pm gilt eigentlich das Gleiche: soll zB. supportedGet überall angeboten werden? Eigentlich braucht man das nur intern.

[A.Harrenberg]

Hi Krikan,

Der Philio PAN04 hat schon V3 und dort gibt es meiner Erinnerung nach Änderungen an der Skalierung, darum war das auch in device_specials gelandet.
Rückwärtskompatibilität der Versionen ist zumeist gegeben, aber man hat halt dann nicht alles.

Ja, die "0x20 bzw. 0x28" deutet darauf hin das Scale in der V3 auf 3 bit erweitert wurde und nicht mehr 2 bit ist.

Die Information zu den  Versionen der Classes wird bisher nicht in Fhem standardmäßig abgefragt und abgespeichert. Das musst Du manuell machen, wobei das dann erzeugte Reading nirgendwo durch Fhem automatisch berücksichtigt wird. Das ist reine User-Info. Im hash steckt dazu nichts. Allgemeines zum hash  findest Du hier: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Der_Hash_einer_Ger.C3.A4teinstanz

Fhem unterscheidet die Versionen der Classes manchmal an den Unterschieden der Nachrichtenlänge (bspw. SENSOR_BINARY), ignoriert die Unterschiede in den Classes durch entsprechende Regex und nutzt damit die Rückwärtskompatitbilität oder bietet Befehle neuerer Versionen immer an (WAKE_UP),...

Theoretisch ist eine Änderung auf andere (bessere?) Berücksichtung der Versionen kein Problem. Bei der Inklusion müssten für alle Classes die Version abgefragt werden und bspw an die jeweiligen Classes im entsprechende Attribut classes als Anhängsel (z.B. METER_3) abgespeichert werden, dann bei set/get/parse entsprechend der Versionen verarbeiten mit Rückfall auf V1. Nächster Schritt wäre dann bei den neueren Versionen über supportedGet die unterstützten Kommandos abzurufen und anzubieten Nur bei mir geht es nicht über die Theorie hinaus; Umsetzung in Code schaffe ich nicht. Den ersten Teil meines Gedankenganges habe ich probiert, bin aber gnadenlos gescheitert. Zudem wird dann in ZWave-Fhem alles deutlich komplizierter und das lastet auf der Schulter eines Anderen

So etwas hatte ich mir auch schon überlegt, bin aber momentan noch nicht mal an dem Punkt das ich scheitern könnte, da fehlen noch ein paar Schritte... ,-)
Ob durch solch eine Umstellung alles viel komplizierter wird kann ich nicht beurteilen, würde aber eigentlich hoffen das es vielleicht erst einmal eine Menge Arbeit ist das Grundgerüst umzustellen, würde im Anschluss daran aber erwarten das es danach genauso einfach, aber vielleicht etwas übersichtlicher wird.
Problem an der Sache wäre aber wahrscheinlich eine nicht gerade Menge an redundanten Funktionen/Code da die meisten Sachen ja doch weitgehend rückwärtskompatibel sind und man bei strenger Trennung der Versionen jedes Mal die Grundfunktionen der vorherigen Versionen neu anlegen müsste.

Da stellt sich  mir grundsätzlich Frage, was soll alles eingebaut sein?. Für mich habe ich testhalber bspw. bei ZWDongle diverse Ergänzungen an den unterstützten Commands vorgenommen, die aber nicht als Patch zur Verfügung gestellt, da die Dinge eigentlich produktiv gar nicht notwendig sind. Die Ergänzungen dienen nur mir, um vielleicht einen tieferen Einblick zu bekommen (was leider nicht immer gelingt). Andere würde mit den Ergänzungen evtl. die Fülle der "unnötigen" Commands und Infos verwirren. Wen so was interessiert, der kann es notfalls auch per raw abrufen. Bei ZWave.pm gilt eigentlich das Gleiche: soll zB. supportedGet überall angeboten werden? Eigentlich braucht man das nur intern.

Ja, die Frage habe ich mir auch schon gestellt, ich kann den Befehl natürlich implementieren und senden, aber was macht man mit dem Report? Lesen und nicken... Da es keinen Mechanismus gibt das Ergebnis für das jeweile Device irgendwie abzulegen und ggf. weiterverwenden zu können macht es eigentlich wenig Sinn. Vielleicht bräuchten wir einen Satze "Experten-Befehle" die erst einbgebunden wird wenn ein entsprechendes Attribut gesetzt ist.

Im Homematic gibt es z.B. das Attribut "expert" mit den Werten "0_off, 1_on, 2_full" das dann mehr Register des Devices anzeigt. Soweit ich das bisher mitbekommen habe hat das aber keinen Einfluss auf die Befehle.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

so, nun habe ich mich mal ein wenig ausgetobt und an den Einträgen für die COMMAND_CLASS_METER rumgeschraubt...
Die Datei geänderte 10_Zwave.pm ist mal angehängt, Kommentare sind ausdrücklich erwünscht, siehe auch die weiteren Punkte im Posting.

Code Auswählen Erweitern

'0097-6943-4501' => { # tapHome Easyplug
  METER                    => {
set   => { meter_reset => "05"
},
get   => { meter       => 'Zwave_meterGet("%s")',
                   meter_V2_energy    => "0100",
                   meter_V2_power     => "0110",
                   meter_V2_supported => "03"
},
parse => { "..3202(.*)" => 'ZWave_meterParse_V2($hash, $1)',
             "..3204(.*)" => 'ZWave_meterSupportedParse_V2($hash, $1)'
}
  }
},
Um nichts "kaputt" zu machen habe ich das ganze erst einmal in deviceSpecial gepackt und und eigene Funktionen *_V2 angelegt.

Es gibt da jetzt einen set meter_reset um den Zähler zu resetten (falls unterstützt), ein get meter_V2_supported um die Eigenschaften von "meter" auszulesen und die Möglichkeit direkt "energy" bzw. "power" auszulesen. Der "normale" get unterstützt das aber auch mit Hilfe eines Parameters.

Beim Parsen der Reports wird V1 und V2 unterstützt und das bei V2 eventuell vorhandene "previous meter value" mit der delta-time ausgegeben. Diese erweiterte Ausgabe kann durch Anlegen eines userattr "METER_V2" mit einem Wert "short_Report" unterdrückt werden.

Hier gehen dann auch schon die Fragen los...

Wie sollte das "get meter" implementiert werden? Aktuell habe ich ja wei Varianten:

• dedizierte Befehle, momentan nur für energy und power (get meter_V2_energy bzw. get meter_V2_power)
• allgemeiner get Befehl der das über einen Parameter auch kann (z.B. über get meter 0 oder get meter 2)

Variante 1 ist für den User einfacher, allerdings müsste da für jede Möglichkeit ein Befehl angelegt werden, ich habe jetzt nur die beiden unterstützten Varianten genommen. In einem allgemeinen Kontext wären da in der METER_V2 drei verschiedenen meter (electric, gas, water) mit jeweils 4 Einheiten definiert, sodass da schon 12 mögliche Befehle zusammen kommen. in der V3 ist die Anzahl der Einheiten anscheinend noch weiter erhöht. Bei dieser Methode würde fast jedes Gerät mit der Command_Class_Meter in deviceSpecial auftauchen um diese Befehle passend zu den unterstützten Fähigkeiten dieses Geräts anzulegen.

Variante 2 ist für den User etwas schwieriger zu bedienen, da er wissen muss welche Einheit er abfragt und ob diese unterstützt wird. Dafür würde es keine deviceSpecial Einträge für ein Gerät benötigen. Eine Abfrage einer nicht unterstützten Einheit führt zu einem Timeout da keine Antwort erfolgt (wäre also "harmlos").

Hier würde ich zu Variante 2 tendieren, andere Meinungen?

Eine weitere Frage ist für mich der Name des jeweiligen Readings.
Bisher wurde einfach "power" oder "energy" ausgegeben. Momentan habe ich das geändert und es wird der "meter_type" ausgegeben. In V2 ist dies "Electric meter", "Gas meter" und "Water meter" (oder "reserved"). Hier ergibt sich dann leider ein Problem das der Readingname nicht eindeutig ist wenn mehr als eine Einheit im meter abgefragt werden kann. Im Beispiel des "Electric meter" z.B. die Energy in kWh und die Power in W, wenn man beides abfragen und auswerten wollte, würden sich die Abfragen im gleichen Reading überschreiben. Daher habe ich übergangsweise " - energy" bzw. " - power" angehängt, finde das aber extrem unschön, vor allem da es eine Art Ausnahme darstellt.

Hier tendiere ich dazu die Einheit mit in den Readingnamen aufzunehmen und die Einheit dann im Reading selbst wegzulassen.
Also z.B.:
Reading name: Electric meter / (kWh)
Reading wert: 0.01633

Das hätte den Vorteil das man auch hier keine weiteren Ausnahmen bräuchte.

Ein (kleines) Problem habe ich dann allerdings mit den previous meter values in der METER_V2. Bisher habe ich das alles inklusive der delta-time in einem Reading ausgegeben:
Electric meter - energy: 0.01633 kWh (previous: 0.015 kWh delta-time: 445 s)

Das würde dann nicht mehr so schön zu dem Reading namen passen wenn dort bereits die Einheit vorhanden ist.
Electric meter / (kWh): 0.01633 (previous: 0.015 delta-time: 445 s)

Diskussionen über Einheiten in den Readings gibt es ja auch bereits so einige, eine eindeutige Antwort habe ich da bisher aber auch noch nicht gefunden.
Und wie sieht es mit Leerzeichen im Reading namen aus? Gibt es da Konventionen?

In der METER_V2 gibt es noch ein Wert "Rate Type" das anzeigt ob Import (consumed) also verbraucht wurde oder ob Export (produced) also erzeugt wurde.
Aktuell gebe ich das noch nicht aus, da mir nicht sicher bin ob das z.B. einfach an das Reading angehängt werden soll:
Electric meter / (kWh): 0.01633 (previous: 0.015 delta-time: 445 s) (consumed)

Hier könnte man das eventuell auch über ein Reading konfigurierbar machen ob das erscheinen soll oder nicht...

Dann hätte ich noch eine Frage zum "Erzeugen" von Readings. Aktuell wird ja der return-String der parse-routine ausgewertet und als EIN Reading angelegt. Wir könnte man hier mehrere Readings erzeugen/beschreiben um z.B. das previous meter value und die delta-time in gesonderte Readings zu schreiben?

So, ganz schön viele Fragen für einen Sonntag...

Gruß,
Andreas.

P.S.: Ich habe mir natürlich fast alles aus dem bestehenden Code abgeschaut, dabei ist mir allerdings aufgefallen das dort nicht berücksichtigt wird das "meter value" als signed value interpretiert werden muss...

[rudolfkoenig]

Bemerkungen zu deinem Patch:
- ohne Doku kommt es nicht rein.
- je kleiner dein Patch ist, desto eher kommt sie rein.
- die Konstanten im Kommentar zu erklaeren finde ich nicht sinnvoll, das Gleiche steht ja auch als code nochmal drin.
- bei deviceSpecial gibt es inzwischen die Funktionalitaet von "get_ADD", damit werden die globalen get Eintraege genommen, und mit der lokalen erweitert. Man kann damit globale Werte ueberschreiben.
- Soweit ich sehe, sollte die bisherige ZWave_meterParse auch in der Lage sein, die V2 Nachrichten zu dekodieren, es werden lediglich die deltaTime und Previous Value Werte ignoriert.

Zu den Fragen:

Wie sollte das "get meter" implementiert werden?

Habe keine Praeferenz, solange es dokumentiert ist.

Name des jeweiligen Readings

Leerzeichen/Sonderzeichen im Namen sind ein No-Go. Ich wuerde die Einheit im Namen mit Unterstrich dranhaengen. Bzw. ich wuerde es so lassen, wie es ist, und damit leben, dass das Reading ueberschrieben wird.
Im Logfile/Notify/etc wird es nicht ueberschrieben, und im Zweifel lieber einfach als perfekt.
Klammern bzw. Sonderzeichen bitte im Reading wenn moeglich vermeiden, die Einheit zu wiederholen (previousValue) ist auch nicht sinnvoll.

eine eindeutige Antwort habe ich da bisher aber auch noch nicht gefunden.

Ich habe schon eine Meinung dazu: Einheit kann man (wenn es nicht klar sein sollte) mit Leerzeichen getrennt hinten dranhaengen, wenn es sich nicht aendert, dann lieber dokumentieren.

Ich wuerde mit der Ausgabe von produced/consumed solange warten, bis einer mit einem konkreten Bedarf sich meldet. Solange nicht nachgewiesenermassen notwendig ist, lieber den Rest nicht verwirren.

Wir könnte man hier mehrere Readings erzeugen/beschreiben

Ist z.Zt. nicht vorgesehen, als Hack kann man unterschiedliche Regexps fuer das Gleiche angeben, siehe ZWave_mfsParse

Alles in allem: ich wuerde pruefen, ob die bisherige ZWave_meterParse nicht reicht, und (falls vorhanden) delta/previous an das zurueckgelieferte Wert hinten dranhaengen.

[A.Harrenberg]

Hallo Rudolf,

Bemerkungen zu deinem Patch:
- ohne Doku kommt es nicht rein.
- je kleiner dein Patch ist, desto eher kommt sie rein.

das sollte jetzt noch keinen Patch darstellen... Soweit ist es ja noch nicht... Da ist ja schon noch was dran zu tun.

- die Konstanten im Kommentar zu erklaeren finde ich nicht sinnvoll, das Gleiche steht ja auch als code nochmal drin.
- bei deviceSpecial gibt es inzwischen die Funktionalitaet von "get_ADD", damit werden die globalen get Eintraege genommen, und mit der lokalen erweitert. Man kann damit globale Werte ueberschreiben.
- Soweit ich sehe, sollte die bisherige ZWave_meterParse auch in der Lage sein, die V2 Nachrichten zu dekodieren, es werden lediglich die deltaTime und Previous Value Werte ignoriert.

Kommentare lassen sich sicherlich einkürzen, aber stört das? Ich finde es schön wenn soetwas im Code kommentiert ist und ich mir nicht anhand des "shift" und der Maske überlegen muss das da jetzt zwei bit an position 5 und 6 gemeint sind.

get_ADD hatte ich auch gesehen, war mir aber nicht sicher ob das so funktioniert wie ich es mir vorgestellt habe. Stimmt aber mit Deiner Erklärung überein und wäre auch eine Möglichkeit.

Ja, die jetzige ZWave_meterParse kann ein "meter value" dekodieren. Was fehlt ist der "rate_type" (consumed/produced), sowie deltaTime/previous value. In der aktuellen Fassung wird dort allerdings das meter value als unsigned ausgewertet, ist aber laut Spezifikation signed.

Was hälst Du denn davon die Ausgabe mittels eines UserAttr zu steuern? Also mein "short_Report"?

Zu den Fragen:
Habe keine Praeferenz, solange es dokumentiert ist.
Leerzeichen/Sonderzeichen im Namen sind ein No-Go. Ich wuerde die Einheit im Namen mit Unterstrich dranhaengen. Bzw. ich wuerde es so lassen, wie es ist, und damit leben, dass das Reading ueberschrieben wird.
Im Logfile/Notify/etc wird es nicht ueberschrieben, und im Zweifel lieber einfach als perfekt.
Klammern bzw. Sonderzeichen bitte im Reading wenn moeglich vermeiden, die Einheit zu wiederholen (previousValue) ist auch nicht sinnvoll.
Ich habe schon eine Meinung dazu: Einheit kann man (wenn es nicht klar sein sollte) mit Leerzeichen getrennt hinten dranhaengen, wenn es sich nicht aendert, dann lieber dokumentieren.

Wenn Du da keine Präferenz hast würde ich wohl auf die Variante 2 mit den (optionalen) Parametern gehen.

Das Leerzeichen im Namen schwierig sein könnten habe ich mir schon gedacht, hat aber erst mal so funktioniert. Das sich die Readings gegenseitig überschreiben fände ich allerdings extrem unschön, dann müsste man z.B. bei einem Notify ja auf die Einheit des Readings filtern wenn man das weiter auswerten möchte. Da würde ich das mit der an den Readingnamen angehängten Einheit bevorzugen.

Es bleibt dennoch das Problem das sich bei "meiner" Variante die Namen der bisherigen Readings "power" und "energy" ändern würden, was bestehende Nutzer sicherlich nicht schön finden würden. Auch hier würde es sich anbieten die Ausgabe bzw. das Verhalten über ein Attribut zu steuern.

Wer kein Attribut setzt hat vorheriges Verhalten, wer aktiv Attribut setzt bekommt die erweiterte Ausgabe.

Alles in allem: ich wuerde pruefen, ob die bisherige ZWave_meterParse nicht reicht, und (falls vorhanden) delta/previous an das zurueckgelieferte Wert hinten dranhaengen.

Ich mache ja im Prinzip nichts anderes, bis zum parsen des ersten meter value ist da nur das rate_type neu in der V2 drin. Danach schaue ich ob noch deltaTime gesendet wurde und lese davon abhängig dann die previous value ein. Das ist ja mit der bisherigen Funktion kompatibel. Einzig die Ausgabe ist unterschiedlich, das wäre aber in Abhängigkeit eines Attributes lösbar.

Gruß,
Andreas.

[rudolfkoenig]

Kommentare lassen sich sicherlich einkürzen, aber stört das?

Ja. Da fange ich naemlich sinnloserweise an zu pruefen, ob der Kommentar mit dem Code uebereinstimmt. Kommentare sind wichtig, aber nur da, wo das Programm was unerwartetes tut, was spaeter nicht aus dem Code offensichtlich ist.

Was hälst Du denn davon die Ausgabe mittels eines UserAttr zu steuern? Also mein "short_Report"?

Wenig, es macht fuer den Benutzer komplizierter. Falls mehr Daten zur Verfuegung stehen, dann wuerde ich sie ausgeben, sonst nicht. Ich moechte das FHEM-ZWave Modul nach dem Prinzip "lieber einfach als perfekt" halten, und nicht so enden wie Homematic, den ich nicht mehr bedienen kann, obwohl ich damit angefangen habe.

[A.Harrenberg]

Hallo Rudolf,

ok, Kommentare kann man kürzen... ,-)

Zum zweiten Punkt: Wenn das ganze nicht irgendwie konfigurierbar ist, wird es zwangsläufig ja mindestens die Änderung in der Ausgabe im Reading geben.

Ich werde mir das ganze jetzt noch mal erneut ansehen und versuchen das so umzusetzen das sich möglichst wenig für die bisherigen Nutzer ändert.
Ich bin mir jetzt nicht ganz sicher ob wir bei ZWave_meterParse das gleiche Verständnis haben. Ich habe zwar eine _V2 Version davon gemacht, da sie aber abwärtskompatibel ist sollte Sie meiner Meinung nach die bisherige ersetzen. (Nachdem ich sie aufgeräumt und angepasst habe). Ich wollte da keine extra Version nur für eine V2 machen.

Ich schau auch mal wie das mit einer Erweitung der Scale auf drei bit (scheint bei V3 so zu sein) aussieht, da könnte dann evtl. bereits der Sonderfall für den Philio_PAN04 entfallen. Allerdings finde ich bisher keine vollständige Dokumentation der Meter_v3.

Ach ja, wenn es denn mal soweit wäre, wie läuft das mit einem Patch? So wie im Wiki beschrieben http://www.fhemwiki.de/wiki/How_to_write_a_patch?

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

so, hab' das ganze jetzt noch mal überarbeitet, der momentane Stand ist angehängt.
Ich habe auch noch ein paar Änderungen für V3 eingebracht soweit das aus dem Code bei OpenZwave und der Anleitung des Philio_Pan04 hervorging. Ich habe auch Thagor angeschrieben und gefragt ob er das mal mit seinem Pan04 testen kann.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

sorry, aber irgendwas habe ich bei den letzten Änderungen kaputt gemacht, Auslesen von Power funktioniert jetzt nicht mehr und wird als energy in kWh gemeldet. ;-(

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

da war ein "my" zu viel drin... ,-(

Sorry, hier eine neue Version, mal sehen was da noch alles drin versteckt ist.

Gruß,
Andreas.

[krikan]

Ach ja, wenn es denn mal soweit wäre, wie läuft das mit einem Patch? So wie im Wiki beschrieben http://www.fhemwiki.de/wiki/How_to_write_a_patch?

Hallo Andreas,
so erstelle ich die Patches und Rudi hat sich darüber nicht beschwert. Ich persönlich fände einen Patch einfacher, damit ich direkt sehe, was Du geändert hast. Bin faul  .
Gruß, Christian

[A.Harrenberg]

Hi Krikan,

sollte ja kein soo grosses Problem sein das Patchfile zu erstellen. Habe eher das Problem das Rudi schneller ist mit anderen Patches und dadurch bei mir viele Unterschiede drin wären die das wieder "rückgängig" machen wollen.

Muss also erst mal rausfinden wie ich die offiziellen Änderungen an der Datei in meine geänderte Datei übernehmen kann ohne meine Sachen zu verlieren. Und dann mal sehen ob Thagor das Modul evtl. mal bei seinem Gerät mit einer METER_V3 testen kann bevor es dann evtl. eingebunden wird. Ich hatte ja schon einen saudummen Fehler eingebaut da ich das ganze noch "eben schnell" fertig machen wollte. Da könnten also noch ein paar weitere lauern.

Gruß,
Andreas.

[rudolfkoenig]

Normalerweise ist Patchfile erstellen kein Problem:
- man checkt die Quellen via SVN aus. Dazu braucht man keine SVN-Schreibberechtigung, Details stehen in fhem/README.svn
- man aendert die Dateien nach belieben.
- man macht regelmaessig ein "svn update .", SVN sorgt fuer das Integrieren der lokalen Aenderungen.
- den Patch erstelt man mit "svn diff ."

Wenn man SVN-Schreibrechte hat, und Modul-Maintainer ist, dann checkt man mit "svn commit" ein.
Fuer SVN gibt es auch Frontends mit grafischer Oberflaeche, fuer Leute die statt viele Knoepfe (Tastatur) weniger (Maus) bevorzugen.