Fragen zu jsonlist

413 views
Skip to first unread message

Hans-Georg Winkler

unread,
Aug 25, 2012, 4:43:01 AM8/25/12
to fhem-de...@googlegroups.com
Hallo Leute,

ich beschäftige mich gerade mit jsonlist und da sind mir ein paar Fragen gekommen:

1) wie erkenne ich z.B. einen Schalter? wenn ich http://fhemhost:port/fhem?cmd=jsonlist Oberlicht&XHR=1 aufrufe bekomme ich

{
  "ResultSet": {
    "Results": {
      "ATTRIBUTES": {
        "room": "Küche"
      },
      "BTN": "01",
      "CODE": {
        "1": "2727 01"
      },
      "CUL_0_MSGCNT": "2",
      "CUL_0_RAWMSG": "F2727011205",
      "CUL_0_RSSI": "-71.5",
      "CUL_0_TIME": "2012-08-25 05:45:47",
      "DEF": "2727 01",
      "IODev": "CUL_0",
      "LASTIODev": "CUL_0",
      "MSGCNT": "2",
      "NAME": "Oberlicht",
      "NR": "159",
      "READINGS": {
        "state": {
          "TIME": "2012-08-25 05:45:47",
          "VAL": "toggle"
        }
      },
      "STATE": "toggle",
      "TYPE": "FS20",
      "XMIT": "2727"
    }
  }
}

doch woran erkenne ich, dass ich jetzt hier in dem Datensatz einen schalter vorliegen habe? TYPE: "FS20" ist ja ein bisschen weit gefasst oder?

2) ich vermisse die Funktionalität mir für einen Raum die Devives zurückgeben zu lassen. Mit "list room='Raumname'" existiert zwar für mich ein Workarround aber wenn jsonlist das gleiche leisten würde wäre die Verarbeitung der Daten für mich ungleich einfacher :-) kann mir jemand sagen wo man den FHEM hierfür anfassen muss? ich habe keine Ahnung wo ich da anfangen soll :-/

OK das wars dann erst mal....

Vielen Dank und Grüße Georg

Dr. Boris Neubert

unread,
Aug 25, 2012, 5:16:42 AM8/25/12
to fhem-de...@googlegroups.com
Hallo,


Am 25.08.2012 10:43, schrieb Hans-Georg Winkler:

1) wie erkenne ich z.B. einen Schalter? wenn ich http://fhemhost:port/fhem?cmd=jsonlist Oberlicht&XHR=1 aufrufe bekomme ich
doch woran erkenne ich, dass ich jetzt hier in dem Datensatz einen schalter vorliegen habe? TYPE: "FS20" ist ja ein bisschen weit gefasst oder?
man könnte sich das "Model"-Attribut zurückgeben lassen oder (ceterum censeo...) die Sache mit den Interfaces (siehe http://fhemwiki.de/wiki/DevelopmentInterfaces) weiterverfolgen.
2) ich vermisse die Funktionalität mir für einen Raum die Devives zurückgeben zu lassen. Mit "list room='Raumname'" existiert zwar für mich ein Workarround aber wenn jsonlist das gleiche leisten würde wäre die Verarbeitung der Daten für mich ungleich einfacher :-) kann mir jemand sagen wo man den FHEM hierfür anfassen muss? ich habe keine Ahnung wo ich da anfangen soll :-/
einbauen FHEM/99_JsonList.pm, vermutlich abkupfern aus fhem.pl, sub CommandList()

Grüße
Boris

Rudolf Koenig

unread,
Aug 25, 2012, 5:32:16 AM8/25/12
to fhem-de...@googlegroups.com
> doch woran erkenne ich, dass ich jetzt hier in dem Datensatz einen schalter
> vorliegen habe? TYPE: "FS20" ist ja ein bisschen weit gefasst oder?

FHEMWEB loest das Problem, indem das jeweilige Geraet mit getAllSets nach der
Liste der moeglichen Set-Kommandos fragt. Diese liefern auch (in begrenztem
Umfeld) moegliche Prameter bzw. Darstellungsform zurueck:
- die Liste ist durch Leerzeichen getrennt.
- falls nach einem Wort, durch Doppelpunkt getrennt eine Komma serparierte
Liste erscheint, dann ist das als Liste der moeglichen Parameter zu
interpretieren.
- falls diese Werte den Form "slider,from,step,to" haben, dann wird auf der
Oberflaeche ein Slider angeboten (fuer den Dimmer).
Das gleiche gilt fuer die Liste der moeglichen Attribute, siehe getAllAttr().

JSonlist (von Martin) scheint weder die Set- noch die Attr-List zu enthalten,
XmlList (ist von mir) enthaelt immerhin die Set-Liste. Ich meine beide
Kommandos sollten beide Listen enthalten, und in der Lage sein, nur bestimmte
Geraete (http://fhem.de/commandref.html#devspec) zurueckzuliefern.
Hier sollte spaeter auch die Liste aller moeglichen Events auftauchen.


Zukunft:
Boris hat mit einer Interface Definition angefangen, auch dokumentiert, und
Stubs in fhem.pl implementiert. Ich meine, dass diese Stubs unnnoetig sind, und
die Entwickler (frontend/backend) unnoetig behindern. Was aber meiner Ansicht
nach notwendig ist, diese Interfaces genau zu dokumentieren, und im Moduldoku
darauf hinzuweisen, welche Interfaces eingehalten werden. Der Rest kann aus
der Liste der sets/attribute/events abgelesen werden.
Wie gesagt, das ist mein (momentane :) Meinung.


Btw.: ZWave implementiert das Interface-Konzept bis auf die Geraete-Ebene,
leider scheitert es teilweise daran, dass diese Interfaces ohne viel Erfahrung
gebaut wurden, z.Bsp. habe ich kein on-for-timer entdeckt, von komplexeren
Einstellungen ganz zu schweigen. Und dann kommt noch dazu die Versionierung der
Interfaces...
Reply all
Reply to author
Forward
0 new messages