FHEM Forum

FHEM - Hausautomations-Systeme => ZWave => Thema gestartet von: A.Harrenberg am 15 Mai 2015, 19:10:48

Titel: Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 15 Mai 2015, 19:10:48
Hallo,

hatte mir zum Ausprobieren und Einstig in Z-Wave einen "EASYPLUG" Zwischenstecker von tapHome gekauft. Das Einbinden in fhem hat soweit auch geklappt, nach der Assoziation wird auch der Status (on/off) zurückgemeldet wenn an der Steckdose mit dem Taster geschaltet wird.

Die Steckdose hat auch ein Verbrauchs-/Leistungsmessung, allerdings kommt das Reading für "power" nicht. Das Reading für "energy" kommt auch nicht, lässt sich aber wenigstens mit get <device> meter abfragen. In den Readings taucht dann noch eine Temperatur auf, die aber anscheinend nichts mit der Raumtemperatur zu tun hat...

Die Anleitung ist leider mehr als dürftig (oder eher weniger als dürftig...) und gibt zu dem Thema so gar nichts her. Auch eine kleine Suche im Internet hat bisher dazu keine Erkenntnisse geliefert.

Die Steckdose wird als model "0x0097 0x6943 0x4501" bzw. modelId "0097-6943-4501" angezeigt, ist also anscheinend nicht in der Datenbank enthalten.

Internals:
   DEF        e173b78d 7
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     11
   NAME       ZWave_SW
   NR         343
   STATE      on
   TYPE       ZWave
   ZWDongle_0_MSGCNT 11
   ZWDongle_0_RAWMSG 000400070a320221140000000d0000
   ZWDongle_0_TIME 2015-05-15 18:46:11
   homeId     e173b78d
   id         07
   lastMsgTimestamp 1431708595.05751
   Readings:
     2015-05-15 09:19:30   assocGroup_01   Max 01 Nodes 01
     2015-05-15 17:27:32   energy          0.19732 kWh
     2015-05-15 09:17:42   humidity        0
     2015-05-15 09:13:34   model           0x0097 0x6943 0x4501
     2015-05-15 09:13:34   modelId         0097-6943-4501
     2015-05-15 18:46:11   power           13 W
     2015-05-15 17:42:35   protection      off
     2015-05-15 18:20:57   reportedState   on
     2015-05-15 18:46:08   state           on
     2015-05-15 18:49:55   swa             on off
     2015-05-15 08:36:22   temperature     30.63 C
     2015-05-15 18:46:08   transmit        OK
Attributes:
   IODev      ZWDongle_0
   classes    SWITCH_BINARY VERSION METER MANUFACTURER_SPECIFIC CONFIGURATION ASSOCIATION PROTECTION POWERLEVEL SENSOR_MULTILEVEL SWITCH_ALL
   room       ZWave


Wenn ich bei eingeschalteter Steckdose einfach nochmal ein "set <device> on" schicke, kommt nach dem Versenden des Befehls eine Antwort mit dem power-Reading:

2015.05.15 18:46:08.534 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.05.15 18:46:08.534 4: ZWDongle_0 transmit OK for 07
2015.05.15 18:46:11.050 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:0a320221140000000d0000


In diesem Fall 13 Watt (0d), was dann auch richtig in den Readings angezeigt wird.

Also Frage Nummer #1: Hat jemand eine Ahnung wie ich dem Gerät beibringe den Wert regelmäßig zu senden? Am besten auch noch die Leistung...

In dem Zusammenhang ist mir bei den Befehlen des Gerätes aber noch was aufgefallen...

An Set-Befehlen wird mir durch das Frontend folgendes angeboten:

associationAdd
associationDel
blink
configByte
configDefault
configLong
configWord
intervals
off
off-for-timer
off-till
on
on-for-timer
on-till
protectionBytes
protectionOff
protectionOn
protectionSeq
swaIncludeNone
swaIncludeOff
swaIncludeOn
swaIncludeOnOff
swaOff
swaOn
toggle


Die meisten Befehle kann ich noch irgendwie Funktionen zuordnen, aber ich finde dabei jetzt nichts wie so ein Reading setzen könnte. Am ehesten hätte ich auf "intervals" gehofft, das erwartet eine Zeitangabe in hh:mm:ss, hat aber nicht den gewünschten Erfolg gebracht.

Viel "interessanter" ist allerdings, das ich im Modul 10_ZWave.pm nicht nachvollziehen kann wo dieser Befehl definiert ist und für welche Klasse er denn wohl gelten würde. Der Befehl ist weder in "%zwave_class" noch in "%zwave_deviceSpecial" definiert!

Wenn man mal einfache eine Zahl hinter den Befehl schreibt kommt im Log eine Fehlermeldung mit einem "define"???
2015.05.15 18:11:28.544 1: define ZWave_SW_intervalNext ZWave_SW_intervalNext at 255 set ZWave_SW intervals 255: Wrong timespec 255: either HH:MM:SS or {perlcode}

Hier dann also Frage #2: Hat jemand eine Ahnung was dieser Befehlt eigentlich macht und wo er definiert ist?

Immer wenn man denkt man hätte das System, nachdem die Befehle zusammengebaut werden, so halb verstanden kommt sowas... ,-)

Gruß,
Andreas.

Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: micha80 am 15 Mai 2015, 19:33:01
Hast du bei den get-Befehlen swbStatus und smStatus?
versuch die beiden mal

intervals <from1>-<till1> <from2>-<till2>...
set the device on for the specified intervals, which are all timespecs in the form HH:MM[:SS]. The intervals are space separated.
-> kommt aus der commandref: weil dein Gerät on/off unterstützt, bekommt es noch ein paar schicke Kommandos spendiert (wie das on-for-timer)
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 15 Mai 2015, 20:04:26
Hallo micha80,

ja, die beiden get-Befehle habe ich.

Bei get <device> smStatus wird die Temperatur geliefert (temperature 43.99 C)
Bei get <device> swbStatus wird der Status zurückgeliefert (state on)

Also auch kein "power"...

Ah, das "intervals" kommte aus dem "Standard"...

Aber nach der Beschreibung ist das ja "nur" eine Zeitschaltuhr und hat dann doch nichts mit den Readings zu tun, schade. Werde mir dann aber doch noch mal ansehen müssen wie dieser "Standard"-Befehl dann eingebunden wird.

Danke schon mal,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: micha80 am 15 Mai 2015, 20:10:10
Könnte smStatus (ich vermute SensorMeter-Status) doch etwas anderes als die Temperatur sein?

Spiel damit mal etwas rum.
(Evtl mit und ohne anschlossene Geräte.)
(Evtl bastelt jemand zu Unrecht das °C dazu...)
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: krikan am 15 Mai 2015, 20:16:44
Hallo Andreas,

das ist ein WINTOP/Schlage Link-Produkt: https://github.com/openhab/openhab/blob/master/bundles/binding/org.openhab.binding.zwave/database/wintop/easyplug.xml
Mehr Infos als die Openhab XML, die auch nicht viel enthält, habe ich leider nicht gefunden. Vielleicht hilft Dir die Info beim Suchen.
Ohne vernünftige Doku zu Parametern und Co. ist es schwierig genaueres zu Deiner 1. Frage zu sagen.
get <device> smStatus ist die Abfrage der Class SENSOR_MULTILEVEL. Vielleicht mal Rohmessage verraten und Version der Class herausfinden.

interval kommt aus den http://fhem.de/commandref#setExtensions , die letztlich über "use SetExtensions;" in die 10_ZWave.pm eingebunden werden.

Gruß, Christian
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: krikan am 15 Mai 2015, 20:18:40
Die entscheidende Abfrage sollte "get <device> meter" sein.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: micha80 am 15 Mai 2015, 20:27:14
sollte ;)
bei meinem Fibaro Wall Plug:
get z_Wall_Plug meter:
energy:0.28 kWh

get z_Wall_Plug smStatus:
power:8.2 W

ich dachte, das ist so gewollt?
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: krikan am 15 Mai 2015, 20:33:56
Ist geräte- und/oder einstellungsabhängig sowie von der Class Version....
Also nichts, was feststeht. Sorry.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: rudolfkoenig am 15 Mai 2015, 20:36:39
Es sind mir zwei Geraetearten bekannt:
- bei der ersten muss man per config dem Geraet mitteilen, dass er die Daten regelmaessig an eine Association-Gruppe senden soll. FHEM setzt bei der Inklusion "set name associationAdd 1 controllerId" ab. Falls das Geraet ueber eine andere Gruppe melden moechte, dann muss man selbst aktiv werden. Die config Befehle sind ueblicherweise auf dem Beipackzettel dokumentiert.
- manche Hersteller vermeiden Lizenzzahlungen, und das Geraet hat so ein Feature gar nicht. Diese muss man mit dem FHEM-Standard at regelmaessig abfragen.

Btw. smStatus und co ist dokumentiert im commandref, im Detail-Fenster ueber "Device specific help" trivial zu erreichen. Warum man raten muss, ist mir wiederum ein Raetsel.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 15 Mai 2015, 23:44:48
Hallo zusammen,

wie gesagt, bei get <device> meter kommt auch nur die "energy".

Bei get <device> smStatus kommt: 42.87 C
ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:063105014210bf
   
4287 = 0x10bf

06 (Länge)
31 (COMMAND_CLASS_SENSOR_MULTILEVEL)
05
01
42
10bf = 4287

In der 050142 ist scaling, precision, sensortype etc. codiert, hier finde ich gerade die Tabelle nicht wieder... ,-(

Der Beipackzettel schweigt sich leider zu diesem Thema vollständig aus. Das mit dem regelmäßig abfragen geht ja nicht mal, da müsste ich regelmäßig "neu" schalten um ein reading für "power" zu bekommen.

Muss mich dann doch noch mal ein wenig durch die openhab und openzwave quellen durcharbeiten und schauen ob sich da nicht doch was zu dem Schalter finden lässt. Momentan sieht es ja leider so aus als ob das Gerät eher in die zweite Kategorie (geht nicht) fallen würde. Weitere Associations scheint das Ding auch nicht zu haben...

Was "Device specifig help" angeht muss ich zugeben das ich das jetzt zum ersten Mal überhaupt wahrgenommen habe...
Das mit den "use SetExtensions;" muss ich mir aber trotzdem mal ansehen damit ich das System dahinter mal etwas besser verstehen lerne.

Gruß,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: krikan am 16 Mai 2015, 00:26:50
Schau bitte mal nach den Claes Versionen, insb. auch von Meter. Meter V3 fehlt z.B. noch.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: krikan am 16 Mai 2015, 08:42:04
Die classVersion von METER bekommst Du mit:
get <device> versionClass 50
Wenn das mindestens 02 ergibt, sollte Hoffnung bestehen. Das "get <device> meter" behandelt derzeit nur V1 und nicht die zusätzlichen Möglichkeiten von V2/V3.
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)
get <ZWDongle> raw 1304043203
wobei Du das erste 04 durch die NodeID Deines Devices ersetzen musst. Wenn es korrekt läuft, erhälst Du ein "011301" angezeigt. Im Log gibt es dann die Rohnachricht mit den Infos welche Abfragen das Gerät unterstützt. Die muss man mit zwapi-PDF und openX-Hilfe analysieren und dann get entsprechend erweitern.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 16 Mai 2015, 08:47:56
Hallo Krikan,
Zitat von: krikan am 16 Mai 2015, 00:26:50
Schau bitte mal nach den Claes Versionen, insb. auch von Meter. Meter V3 fehlt z.B. noch.
das hatte ich mir für heute vormittag vorgenommen...

SWITCH_BINARY 0x25/37 V1
VERSION 0x86/134 V1
METER 0x32/50 V2
MANUFACTURER_SPECIFIC 0x72/114 V1
CONFIGURATION 0x70/112 V1
ASSOCIATION 0x85/133 V1
PROTECTION 0x75/117 V1
POWERLEVEL 0x73/115 V1
SENSOR_MULTILEVEL 0x31/49 V1
SWITCH_ALL 0x27/39 V1


versionClass_20 01
versionClass_25 01
versionClass_27 01
versionClass_31 01
versionClass_32 02
versionClass_70 01
versionClass_72 01
versionClass_73 01
versionClass_75 01
versionClass_85 01
versionClass_86 01


Meter ist also "nur" V2.

Gibt es eigentlich irgendwo eine Auflistung welche Command Class in welcher Version aktuell von fhem unterstützt wird? Im Code kann ich zwar sehen welche Command Class Befehler hinterlegt hat, aber für welche Version das ist geht daraus für mich irgendwie nicht hervor.

Gruß,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: krikan am 16 Mai 2015, 08:59:28
ZitatMeter ist also "nur" V2.
Könnte schon reichen, siehe meinen letzten Post. Bitte "supportetGet" abfragen.

ZitatGibt es eigentlich irgendwo eine Auflistung welche Command Class in welcher Version aktuell von fhem unterstützt wird?
Mir nicht bekannt. Sicherheit gibt es nur über Anlayse. Grundregel "get" und "set" sind häufig nur V1, während für "parse" die Auswertungen oft auch höhere Versionen unterstützen. Das liegt auch am Konzept der Nachrichten von ZWave. Wenn Du es analysierst, kannst Du das gerne dokumentieren. Du hast im Wiki schon einen sehr ausführlichen Artikel zum Tagreader geschrieben, vielen Dank dafür.

Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: rudolfkoenig am 16 Mai 2015, 09:06:32
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 16 Mai 2015, 09:12:27
Hi Krikan,

Zitat von: krikan am 16 Mai 2015, 08:42:04
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.

Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 16 Mai 2015, 11:00:11
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.

Zitat von: rudolfkoenig am 16 Mai 2015, 09:06:32
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: krikan am 16 Mai 2015, 15:22:47
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 16 Mai 2015, 16:25:03
Hi Krikan,

Zitat von: krikan am 16 Mai 2015, 15:22:47
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.

Zitat von: krikan am 16 Mai 2015, 15:22:47
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.

Zitat von: krikan am 16 Mai 2015, 15:22:47
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 17 Mai 2015, 13:14:09
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.

'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:

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...
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: rudolfkoenig am 17 Mai 2015, 14:33:18
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:
ZitatWie sollte das "get meter" implementiert werden?
Habe keine Praeferenz, solange es dokumentiert ist.

ZitatName 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.

Zitateine 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.

ZitatWir 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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 17 Mai 2015, 15:38:33
Hallo Rudolf,

Zitat von: rudolfkoenig am 17 Mai 2015, 14:33:18
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.

Zitat von: rudolfkoenig am 17 Mai 2015, 14:33:18
- 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"?

Zitat von: rudolfkoenig am 17 Mai 2015, 14:33:18
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.

Zitat von: rudolfkoenig am 17 Mai 2015, 14:33:18
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: rudolfkoenig am 17 Mai 2015, 15:52:15
ZitatKommentare 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.

ZitatWas 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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 17 Mai 2015, 16:22:21
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 (http://www.fhemwiki.de/wiki/How_to_write_a_patch)?

Gruß,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 17 Mai 2015, 20:27:54
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 17 Mai 2015, 21:51:29
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 17 Mai 2015, 22:15:42
Hallo,

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

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

Gruß,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: krikan am 18 Mai 2015, 17:23:10
Zitat von: A.Harrenberg am 17 Mai 2015, 16:22:21
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 (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
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 18 Mai 2015, 18:39:17
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: rudolfkoenig am 18 Mai 2015, 18:57:07
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.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 18 Mai 2015, 22:36:46
Hallo Rudi, hallo Krikan,

leider hat sich Thargor bisher nicht gemeldet um zu sagen ob er die geänderte Version mal bei sich probieren könnte. Wenn alles so funktioniert wie ich es mir vorstelle würde sich die Sonderbehandlung für diesen Pan04 ja erübrigen, das Device habe ich in deviceSpecial gelassen, da dort ja die "Spezialbefehle" hinterlegt sind, die Auswertung sollte auch ohne die gesonderten Abfragen für das Device funktionieren.

Ansonsten wäre das mit dieser ersten V3 Implementierung ungetestet, in dem Thread von damals habe ich auch keine passenden Logs gefunden an denen ich das wenigstens theoretisch überprüfen könnte. So ist es jetzt anhand der Anleitung des Pan04 bzw. aus dem C++ Code von OpenZWave  umgesetzt. Immerhin stimmen die Beschreibungen der beiden Quellen überein ,-)

Von euch hat nicht zufällig einer ein Gerät mit einer METER_V3?

Ich habe mal ein Patch File erstellt und angehängt, bin mir selbst aber noch nicht so ganz sicher ob das ungetestet in die freie Wildbahn sollte.
@ Rudi: kannst Du mal schauen ob das File zumindest im richtigen Format wäre? Hab es mit subversion erstellt, sollte also eigentlich passen.

Gruß,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 18 Mai 2015, 22:50:19
Hi,

Thargor hat sich gerade gemeldet und wird das freundlicher Weise mal testen.

Gruß,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: rudolfkoenig am 19 Mai 2015, 09:27:17
Gegen dem Patch habe ich generell nichts einzuwenden, ich habe nur folgende Anmerkungen:
- bitte die Daten mit einem Leerzeichen vom Rest abgrenzen (previous:XX, delta_time:YY), damit die Auswertung (FileLog/SVG) ohne Verrenkungen damit arbeiten kann.
- du koenntest mir noch das Leben vereinfachen, indem Du auf eine Zeilenbreite von 80 achtest, sonst muss ich das noch umformatieren.

Und bitte Bescheid geben, wenn es "reif" ist.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: Thargor am 19 Mai 2015, 11:33:18
Hallo,

ich hab Andreas schon geschrieben. Prinzpipell funktioniert das bei mir, allerdings wird kein Voltage und Ampere zurückgemeldet und daher kann man die dann auch nicht mehr abfragen:


get metersupport:
meterSupported: type:energy scales:0:kWh, 2:W resetable:yes
2015.05.19 11:10:44 2: ZWave get ZWave_SWITCH_BINARY_18 meterSupported
2015.05.19 11:10:44 4: ZWaveUSB CMD:ZW_SEND_DATA ID:00 ARG:
2015.05.19 11:10:44 4: ZWaveUSB transmit OK for 03
2015.05.19 11:10:44 4: ZWaveUSB CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:0432048175

get device meter:
energy:0 kWh previous:0 delta_time:9904 s
2015.05.19 11:14:12 2: ZWave get ZWave_SWITCH_BINARY_18 meter
2015.05.19 11:14:12 4: ZWaveUSB CMD:ZW_SEND_DATA ID:00 ARG:
2015.05.19 11:14:12 4: ZWaveUSB transmit OK for 02
2015.05.19 11:14:12 4: ZWaveUSB CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:0e320221440000000026b000000000

get device meter 0:
energy:0 kWh previous:0 delta_time:107 s
2015.05.19 11:15:58 2: ZWave get ZWave_SWITCH_BINARY_18 meter
2015.05.19 11:15:58 4: ZWaveUSB CMD:ZW_SEND_DATA ID:00 ARG:
2015.05.19 11:15:58 4: ZWaveUSB transmit OK for 32
2015.05.19 11:15:59 4: ZWaveUSB CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:0e3202214400000000006b00000000

get device meter 2:
power:0 W
2015.05.19 11:16:55 2: ZWave get ZWave_SWITCH_BINARY_18 meter
2015.05.19 11:16:55 4: ZWaveUSB CMD:ZW_SEND_DATA ID:00 ARG:
2015.05.19 11:16:55 4: ZWaveUSB transmit OK for 32
2015.05.19 11:16:55 4: ZWaveUSB CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:0e3202213400000000000000000000

set device meterreset:
2015.05.19 11:23:22 2: ZWave set ZWave_SWITCH_BINARY_18 meterReset
2015.05.19 11:23:22 4: ZWaveUSB CMD:ZW_SEND_DATA ID:00 ARG:
2015.05.19 11:23:22 4: ZWaveUSB transmit OK for 12

get device meterAmpere
current:0 A
2015.05.19 11:17:58 2: ZWave get ZWave_SWITCH_BINARY_18 meterAmpere
2015.05.19 11:17:58 4: ZWaveUSB CMD:ZW_SEND_DATA ID:00 ARG:
2015.05.19 11:17:58 4: ZWaveUSB transmit OK for 32
2015.05.19 11:17:58 4: ZWaveUSB CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:0a3202a14a000000000000

get device meterVoltage
voltage:232.4 V
2015.05.19 11:19:12 2: ZWave get ZWave_SWITCH_BINARY_18 meterVoltage
2015.05.19 11:19:12 4: ZWaveUSB CMD:ZW_SEND_DATA ID:00 ARG:
2015.05.19 11:19:12 4: ZWaveUSB transmit OK for 32
2015.05.19 11:19:12 4: ZWaveUSB CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:0a3202a122091400000000


Gruß Lars
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 19 Mai 2015, 19:41:12
Hi,

habe bei der Erweiterung von der V2 auf die V3 vergessen eine Schleife länger laufen zu lassen, neue Version im Anhang.

BTW. Stört die "lange Ausgabe" mit der previos value und der delta-time irgendwie?

Danke für's testen,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: Thargor am 19 Mai 2015, 20:33:32
Zitat von: A.Harrenberg am 19 Mai 2015, 19:41:12
Hi,

habe bei der Erweiterung von der V2 auf die V3 vergessen eine Schleife länger laufen zu lassen, neue Version im Anhang.

BTW. Stört die "lange Ausgabe" mit der previos value und der delta-time irgendwie?

Danke für's testen,
Andreas.

Neue Version klappt mit dem Pan04 nun problemlos.

get meterSupported liefert nun:
meterSupported: type:energy scales:0:kWh, 2:W, 4:V, 5:A, 6:powerFactor resetable:yes

Gruß Lars
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: det. am 19 Mai 2015, 20:58:58
getestet...  Danke, geht prima und bringt keine neuen unerwünschten Meldungen ins logfile. Auch wenn die Messung des Energieverbrauchs nicht der Grund der Anschaffung der 2 Funksteckdosen war.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 19 Mai 2015, 22:24:45
Hallo Rudi,

nachdem das jetzt getestet ist und anscheinend keine offensichtlichen Probleme macht habe ich mal ein neues Patchfile erstellt und definiere das jetzt mal als "reif".

Ich habe jetzt noch Leerzeichen zwischen den Werten eingefügt und den Code auf 80 Zeichen umgebrochen.

Die besondere Ausleseroutine für den Pan04 habe ich ja entfernt, das geht ja jetzt mit dem normalen Code. Ich habe aber noch die "speziellen" get-Befehle aus deviceSpecial drin gelassen. Das sind die gleichen Befehle die auch mit get <device> meter und Angabe des codes für die Einheit erzeugt werden. Theoretisch könnten die also entfallen, würde aber bedeuten das z.B. Thargor dann wahrscheinlich einige Befehle umschreiben muss.

Außer den paar mehr Zeilen in deviceSpecial tun die aber auch nicht weh...

Gruß,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: rudolfkoenig am 20 Mai 2015, 08:17:55
Hab deine Patches mit kleinen Aenderungen (syntaktischer Natur) eingecheckt.

Thargor muss sich leider anpassen: die speziellen gets habe ich entfernt, da ich nicht will, dass mehr Leute anfangen diese Funktionen zu verwenden.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: A.Harrenberg am 20 Mai 2015, 12:05:43
Hallo Rudolf,
Zitat von: rudolfkoenig am 20 Mai 2015, 08:17:55
Hab deine Patches mit kleinen Aenderungen (syntaktischer Natur) eingecheckt.
ok, Danke, die Änderungen werde ich mir dann mal ansehen und wahrscheinlich wieder was lernen ,-)

Zitat von: rudolfkoenig am 20 Mai 2015, 08:17:55
Thargor muss sich leider anpassen: die speziellen gets habe ich entfernt, da ich nicht will, dass mehr Leute anfangen diese Funktionen zu verwenden.

Wäre auch meine Intention gewesen, wollte das aber nicht direkt vorschlagen...

Gruß,
Andreas.
Titel: Antw:Keine regelmäßigen Power-Readings bei tapHome EASYPLUG
Beitrag von: Thargor am 20 Mai 2015, 21:23:22
Zitat von: rudolfkoenig am 20 Mai 2015, 08:17:55
Thargor muss sich leider anpassen: die speziellen gets habe ich entfernt, da ich nicht will, dass mehr Leute anfangen diese Funktionen zu verwenden.

Passe mich da gerne an, wenn damit die Sonderbehandlung entfernt werden kann.

Gruß Lars