Standard Weg zur Parameterabfrage

[kohrti]

Hallo,

ich habe eine Abfrage wie z.B.:

get Vorlauftemperatur param temperature

Nun war das ergebnis bisher einfach nur die Zahl. Seit heute bekomme ich folgende Informationen:

name: Vorlauftemperatur     temperature:33.5

Da ich diese Abfrage in perl eingebaut habe für ein Heizungssteuerungsmodul, würde mich interessieren warum das gemacht wurde und ob diese Änderung dauerhaft ist?
Gibt es dazu eine Doku? (Ich konnte in der commandref nichts bzgl. einer Änderung finden.)

Jetzt muss ich das in perl mit split oä. bearbeiten damit ich wieder nur die Zahl erhalte.

Gruß
Christian

[UliM]

Hi,
von welchem fhem-Typ ist denn das Ding namens "Vorlauftemperatur"?
Gruß, Uli

[Christian Kohrt]

Das ist ein Temperatursensor (subType THSensor). Aber das Problem ist von genereller Natur. Irgendjemand dachte sich wohl, dass es schön ist bei Parameterabfragen auch den Namen des Devices und des Parameters mit zu liefern. Ist ja auch ok, ich würde nur erwarten, dass das dann auch irgendwo dokumentiert ist. Vielleicht hab ich ja eine Möglichkeit übersehen, wie man eine Abfrage macht und NUR den Wert zurück bekommt. Kann ich natürlich auch selbst in das Utility Modul schreiben (mit einer split Funktion etc.), aber so ein Problem muss zentral gelöst werden (bzw. ich bin überzeugt es wurde bereits gelöst) und ich mag keinen redundanten Code.

 

Also daher meine neue Fragestellung:

Kennt jemand eine Abfrage, bei der NUR der Wert des Parameters zurück kommt?

--
To unsubscribe from this group, send email to
fhem-users+...@googlegroups.com

[UliM]

subType - also CUL_HM?
=8-)

[Christian Kohrt]

Oh sorry, ja cul hm!

Von meinem iPhone gesendet

Am 17.11.2012 um 20:03 schrieb UliM <uli....@gmail.com>:

subType - also CUL_HM?
=8-)

[UliM]

Hi,
Martin entwickelt gerade CUL_HM weiter und leistet echt Großes. Bitte hab etwas Nachsicht mit ihm :) Er wird diesen Fred vmtl aber nicht lesen, wenn CUL_HM nicht im Betreff steht.
Kannst Du daher bitte den Betreff des posts ändern, so dass CUL_HM drinsteht.

Kann sein dass er die GetFn geändert hat, dazu müsste dann er was sagen.

Gruß, Uli

[kohrti]

Hallo Uli,

keine Frage, Martin leistet wirklich super Arbeit. Wenn ich mehr Infos hätte könnte ich ihm vielleicht auch helfen. Er arbeitet ja schon seit Tagen/Wochen an der Thermostate Geschichte und wahrscheinlich noch einige andere Baustellen... daher echt Hut ab! Ohne ihn würde vieles wahrscheinlich in weite Ferne rücken!

Naja, ich ändere mal den Betreff, vielleicht liest er das ja. Ist aber auch kein Ding, er hat bestimmt auch anderes zu tun... :)

Viele Grüße,
Christian

[Martin]

Hallo

habe es doch gelesen ;-)

keine Frage, Martin leistet wirklich super Arbeit.

danke - manches ist noch etwas experimentell....

Wenn ich mehr Infos hätte könnte ich ihm vielleicht auch helfen.

 welche Parameter hat den dein thsensor alles? kannst du mit list nachsehen

Ich habe etwas geaendert - und zwar, dass die Parameter der Kanaele beruecksichtigt werden sollen.
Evtl. muss ich dies ueberdenken - macht hier evtl keinen Sinn.. mal drueber schlafen

Funktion ist, dass - wenn du das Kommando auf ein device anwendest, es dir alle matches der Unterkanaele schickt.
Wenn du es nur auf einen Kanal anwendest kommt nur dessen Datum..

Danke
Martin

[kohrti]

Hallo Martin (wieder einmal :) ),

also list ergibt folgendes:

Internals:
   CUNO_MSGCNT 181
   CUNO_RAWMSG A0C5E86701953E7000000016564F1
   CUNO_RSSI  -81.5
   CUNO_TIME  2012-11-17 23:41:47
   DEF        1953E7
   IODev      CUNO
   LASTIODev  CUNO
   MSGCNT     181
   NAME       Vorlauftemperatur
   NR         200
   STATE      T: 35.7 H: 100
   TYPE       CUL_HM
   lastMsg    No:5E - t:70 s:1953E7 d:000000 016564
   Readings:
     2012-11-17 23:41:47   humidity        100
     2012-11-17 23:41:47   state           T: 35.7 H: 100
     2012-11-17 23:41:47   temperature     35.7
   Helper:
     mId        003E
     rxType     12
     Respwait:
Attributes:
   devInfo    010100
   firmware   1.2
   hmClass    sender
   model      HM-WDS30-T-O
   protCmdDel 0
   protLastRcv 2012-11-17 23:41:47
   protSndCnt 2
   protSndLast 2012-10-06 23:22:12
   room       Heizung
   serialNr   JEQ0058957
   subType    THSensor

Ich wollte garnicht so tief einsteigen und Arbeit erzeugen. Mir ist nur aufgefallen, dass der Befehl:

get Vorlauftemperatur param temperature

seit der heutigen Version zu folgendem Ergebnis führt:

name: Vorlauftemperatur     temperature:33.5

Da wurde meiner Meinung nach einfach mehr Infos in die Antwort reingesteckt was ja eigentlich auch gut ist. Die Funktion hat sich halt verändert, aber ich frage mich ob es auch eine Abfrage gibt, womit ich nur, z.B. "33.5", erhalte, also das was ich wissen möchte (wie in der Version früher). Aber ich kann mir auch eine perl utility Funktion basteln. Hier geht es nur um Schönheit....

Besten Gruß,
Christian

[Martin]

Also ein roter Faden ist, dass Kommandos auf ein Device, wenn sinnvoll - auch entsprechend auf die Kanaele wirken. So ein getConfig, get reg, status, getdevicepair...

Hier wollte ich beispielsweise den Status aller Kanaele sehen, wenn ich ein device anfrage.
Aber ich denke, ich liegen hier semantisch falsch. Eine Abfrage nach -einem- parameter sollte auch -einen- Wert zurueckliefern.

Evtl wuerde eine Abfrage "get<dev> <param> all" der Sache naeher kommen, die ich gemeint habe. Aber vielleicht macht es hier einfach keinen sinn.

Ich werde es wieder zurueckdrehen.

Was meint ihr - macht ein 'all' bei param sinn? eher nicht meine ich jetzt...war uebereifrig :-(

bei "get ...reg all" macht es schon sinn. Hier muss ich aber noch etwas nachbessern.... beispielsweise beim TC. Der hat eine recht komplexe Struktur und die Anzeigen ist nicht korrekt. Jeder Kanal ein Unikum. Da aendert sich noch etwas. Aber nicht beim Lesen eines einzelnen Registers.
Dazugekommen ist bei Registern die Nutzung von "Literals" - also 'auto' und 'party' anstatt die Nummern. Auch bei Register setzen und lesen. Bei TC wird evtl. das bisherigen Interface genutzt - aber bei anderen devices ist dies der weg zum Einstellen.

Gruss
Martin

[kohrti]

Hi Martin,

die Frage ist doch die: Wenn ich eine Liste habe mit Einträgen in der Form "Device Name Parameter Name Wert", wie erhalte ich denn den Wert eines jeden Eintrages? Da muss es doch eine Utility Funktion geben, die mir für jeden Listeneintrag den Wert zurückgibt, oder? Und genau diese Funktion könnte ich auch für einen einzelnen Wert verwenden. Somit würden Listeneinträge und einzelne Abfragen genau gleich behandelt. Dann wäre die bestehende Implementierung "generisch" und richtig und es müßte nur diese Utility Funktion hinzugefügt werden. Und das ist eigentlich meine Frage gewesen, wo es diese Funktion gibt. (Selbstgeschrieben ist sie ja schnell aber ich dachte eben nur dass es sie evtl. schon gäbe). Letztlich ist beides richtig und eine Frage wo weniger Aufwand dahinter steht und was generischer ist um die SW auch wartbar zu behalten.

In perl kenn ich mich nicht so gut aus, aber ich bemühe mich. Wenn es diese Utility Funktion noch nicht gibt, kann ich die (sozusagen als Übung) auch schreiben (in 99_Utils.pm) und in SVN einchecken.

Mein Aufruf war "get<dev> <param>" ohne dem "all".  Mit dem "all" hast du mich abgehängt... aber ich glaube du verstehst schon was ich meine. Gib Bescheid wenn ich was machen kann und wie du dich entschieden hast.

Gruß
Christian

[Martin]

Am Sonntag, 18. November 2012 01:54:36 UTC+1 schrieb kohrti:

Hi Martin,

die Frage ist doch die: Wenn ich eine Liste habe mit Einträgen in der Form "Device Name Parameter Name Wert", wie erhalte ich denn den Wert eines jeden Eintrages?

korrekt - mein fehler. ist schon behoben. Als ich es urspruenglich gebaut habe war genau das mein Ziel. In einer Nachtaktion habe ich dann das mit dem Device eingebaut - war bloed.

Mein Aufruf war "get<dev> <param>" ohne dem "all".  Mit dem "all" hast du mich abgehängt... aber ich glaube du verstehst schon was ich meine. Gib Bescheid wenn ich was machen kann und wie du dich entschieden hast.

sollte schon wieder gehen - seit gestern nacht (2131) - hoffe ich

Gruss
Martin