Lupus Alarmanlage mit Httpmod/JSON auslesen

Begonnen von stenny, 07 Oktober 2018, 12:29:42

Vorheriges Thema - Nächstes Thema

stenny

Hallo

Versuche gerade eine Lupus Alarmanlage (XT1+) mit HttpMod auszulesen.

Der Status Funktioniert ohne Fehler

{
  "updates" : {
    "mode_a1" : "{AREA_MODE_1}",
    "mode_a2" : "{AREA_MODE_1}",
    "dc_ex" : "1",
    "alarm_ex" : "0",
    "battery_ex" : "1",
    "battery_ok" : "1",
    "battery" : "{WEB_MSG_NORMAL}",
    "tamper_ok" : "1",
    "tamper" : "{WEB_MSG_NORMAL}",
    "interference_ok" : "1",
    "interference" : "{WEB_MSG_NORMAL}",
    "ac_activation_ok" : "1",
    "ac_activation" : "{WEB_MSG_NORMAL}",
    "sys_in_inst": "",
    "rssi" : "1",
    "sig_gsm_ok" : "1",
    "sig_gsm" : "{WEB_MSG_NA}"
  },
  "forms" : {
    "pcondform1" : {
      "mode" : "1",
      "f_arm" : "0"
    },
    "pcondform2" : {
      "mode" : "1",
      "f_arm" : "0"
    }
  }
}


Nur bei den Sensoren werden über extractAllJSON 1 keine Readings erstellt

{
  "senrows": [
{"area": 1, "zone": 1, "type": 37, "type_f": "{D_TYPE_37}", "name": "Eingang",
"cond": "", "cond_ok": "1", "battery": "", "battery_ok": "1",
"tamper": "", "tamper_ok": "1", "bypass": 0, "rssi": "{WEB_MSG_STRONG} 9",
"resp_mode": [0,5,5,5,5,0], "ammeter": "0", "ver": "",
"hue": "-1", "sat": "-1", "bypass_tamper": 0,
"status": "", "sid": "RF:0073ed70", "su": 0, "alarm_status": "", "status_ex": "0"},
{"area": 2, "zone": 1, "type": 9, "type_f": "{D_TYPE_9}", "name": "BM Treppenhaus",
"cond": "", "cond_ok": "1", "battery": "", "battery_ok": "1",
"tamper": "", "tamper_ok": "1", "bypass": 0, "rssi": "{WEB_MSG_STRONG} 9",
"resp_mode": [0,0,0,0,0,0], "ammeter": "0", "ver": "",
"hue": "-1", "sat": "-1", "bypass_tamper": 0,
"status": "", "sid": "RF:04435330", "su": 1, "alarm_status": "", "status_ex": "0"},
{"area": 1, "zone": 2, "type": 4, "type_f": "{D_TYPE_4}", "name": "Wohnungstür",
"cond": "", "cond_ok": "1", "battery": "", "battery_ok": "1",
"tamper": "", "tamper_ok": "1", "bypass": 0, "rssi": "{WEB_MSG_STRONG} 9",
"resp_mode": [3,1,1,1,1,0], "ammeter": "0", "ver": "",
"hue": "-1", "sat": "-1", "bypass_tamper": 0,
"status": "{WEB_MSG_DC_CLOSE}", "sid": "RF:04993310", "su": 1, "alarm_status": "", "status_ex": "0"}]
}


Im Log erhalte ich

2018.10.07 12:14:02 5: HttpUtils https://xxx:xxx@ip/action/deviceListGet: Got data, length: 1260
2018.10.07 12:14:02 5: HttpUtils response header:
HTTP/1.0 200 OK
Server: Mongoose
Pragma: no-cache
Cache-control: no-cache
Expires: 0
Content-Type: application/json; charset=utf-8
2018.10.07 12:14:02 4: Alarmanlage_device: Read callback: request type was update retry 0,
Body: {
  "senrows": [
{"area": 1, "zone": 1, "type": 37, "type_f": "{D_TYPE_37}", "name": "Eingang",
"cond": "", "cond_ok": "1", "battery": "", "battery_ok": "1",
"tamper": "", "tamper_ok": "1", "bypass": 0, "rssi": "{WEB_MSG_STRONG} 9",
"resp_mode": [0,5,5,5,5,0], "ammeter": "0", "ver": "",
"hue": "-1", "sat": "-1", "bypass_tamper": 0,
"status": "", "sid": "RF:0073ed70", "su": 0, "alarm_status": "", "status_ex": "0"},
{"area": 2, "zone": 1, "type": 9, "type_f": "{D_TYPE_9}", "name": "BM Treppenhaus",
"cond": "", "cond_ok": "1", "battery": "", "battery_ok": "1",
"tamper": "", "tamper_ok": "1", "bypass": 0, "rssi": "{WEB_MSG_STRONG} 9",
"resp_mode": [0,0,0,0,0,0], "ammeter": "0", "ver": "",
"hue": "-1", "sat": "-1", "bypass_tamper": 0,
"status": "", "sid": "RF:04435330", "su": 1, "alarm_status": "", "status_ex": "0"},
{"area": 1, "zone": 2, "type": 4, "type_f": "{D_TYPE_4}", "name": "Wohnungstür",
"cond": "", "cond_ok": "1", "battery": "", "battery_ok": "1",
"tamper": "", "tamper_ok": "1", "bypass": 0, "rssi": "{WEB_MSG_STRONG} 9",
"resp_mode": [3,1,1,1,1,0], "ammeter": "0", "ver": "",
"hue": "-1", "sat": "-1", "bypass_tamper": 0,
"status": "{WEB_MSG_DC_CLOSE}", "sid": "RF:04993310", "su": 1, "alarm_status": "", "status_ex": "0"}]
}

2018.10.07 12:14:02 3: Alarmanlage_device: error while parsing JSON data: invalid character encountered while parsing JSON string, at character offset 230 (before "\t9", \n"resp_mode":...") at (eval 2730) line 1.

2018.10.07 12:14:02 5: Alarmanlage_device: ExtractSid called, context reading, num
2018.10.07 12:14:02 4: Alarmanlage_device: CheckAuth decided no authentication required
2018.10.07 12:14:02 3: Alarmanlage_device: no parsed JSON structure available
2018.10.07 12:14:02 5: Alarmanlage_device: Read starts parsing response to update with defined readings:
2018.10.07 12:14:02 3: Alarmanlage_device: Read response to update didn't match any Reading
2018.10.07 12:14:02 5: Alarmanlage_device: HandleSendQueue called, qlen = 0


List....
Internals:
   BUSY       0
   CHANGED   
   DEF        https://xxx:xxx@ip/action/deviceListGet 60
   Interval   60
   JSONEnabled 1
   LASTSEND   1538907961.40994
   MainURL    https://xxx:xxx3de@ip/action/deviceListGet
   ModuleVersion 3.5.1 - 5.7.2018
   NAME       Alarmanlage_device
   NR         530
   STATE      ???
   TRIGGERTIME 1538908021.40683
   TRIGGERTIME_FMT 2018-10-07 12:27:01
   TYPE       HTTPMOD
   addr       https://ip
   auth       1
   code       200
   compress   1
   conn       
   data       
   displayurl https://xxx:xxx@ip/action/deviceListGet
   header     
   host       192.168.2.198
   httpheader HTTP/1.0 200 OK
Server: Mongoose
Pragma: no-cache
Cache-control: no-cache
Expires: 0
Content-Type: application/json; charset=utf-8
   httpversion 1.0
   hu_blocking 0
   hu_filecount 33
   hu_port    443
   hu_portSfx
   ignoreredirects 0
   loglevel   4
   path       /action/deviceListGet
   protocol   https
   pwd        L563fbe3de
   redirects  0
   timeout    2
   url        https://xxx:xxx@ip/action/deviceListGet
   user       ckuntze
   value      0
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1538907271.62737
           VALUE      reread
   QUEUE:
   READINGS:
   REQUEST:
     data       
     header     
     ignoreredirects 0
     retryCount 0
     type       update
     url        https://xxx:xxx@ip/action/deviceListGet
     value      0
   sslargs:
Attributes:
   enableControlSet 1
   enforceGoodReadingNames 1
   extractAllJSON 1
   room       Lupus
   verbose    5


Wenn ich die Regex umgehen könnte würde es später einfacher wenn alle Sensoren angelernt wären.....

Für Hilfe oder Ideen wäre ich dankbar


Carsten

Rudibarani

Hallo Carsten,

ich habe das bei mir so gelöst:

define Alarmanlage HTTPMOD http://***user***:***password***@192.0.0.140/action/panelCondGet 30
attr Alarmanlage userattr get01Name get01Poll:0,1 get01URL getEncode reading01JSON reading01Name reading01OMap reading02JSON reading02Name reading02OMap reading03JSON reading03Name reading03OMap reading04JSON reading04Name reading04OMap reading05JSON reading05Name reading05OMap reading06JSON reading06Name reading06OMap reading07JSON reading07Name reading07OMap reading08JSON reading08Name reading08OMap readingEncode
attr Alarmanlage enableControlSet 1
attr Alarmanlage event-on-change-reading .*
attr Alarmanlage getEncode UTF-8
attr Alarmanlage icon building_security
attr Alarmanlage reading01JSON forms_pcondform1_mode
attr Alarmanlage reading01Name Modus_Nacht
attr Alarmanlage reading01OMap 0:Aus, 1:Scharf, 2:Nacht
attr Alarmanlage reading02JSON forms_pcondform2_mode
attr Alarmanlage reading02Name Modus_Abwesend
attr Alarmanlage reading02OMap 0:Aus, 1:Scharf, 2:Nacht
attr Alarmanlage reading03JSON updates_alarm_ex
attr Alarmanlage reading03Name Alarm_Status
attr Alarmanlage reading03OMap 0:OK, 1:Alarm
attr Alarmanlage reading04JSON updates_ac_activation_ok
attr Alarmanlage reading04Name Strom_Status
attr Alarmanlage reading04OMap 1:OK, 0:Stromausfall
attr Alarmanlage reading05JSON updates_tamper_ok
attr Alarmanlage reading05Name Sabotage
attr Alarmanlage reading05OMap 1:OK, 0:Sabotagealarm
attr Alarmanlage reading06JSON updates_battery_ok
attr Alarmanlage reading06Name Batterie
attr Alarmanlage reading06OMap 1:OK, 0:Batterie schwach
attr Alarmanlage reading07JSON updates_sig_gsm_ok
attr Alarmanlage reading07Name GSM_Status
attr Alarmanlage reading07OMap 1:OK, 0:GSM Verbindungsfehler
attr Alarmanlage reading08JSON updates_interference_ok
attr Alarmanlage reading08Name Signalinterferenz
attr Alarmanlage reading08OMap 1:OK, 0:Funktstörung
attr Alarmanlage readingEncode UTF-8
attr Alarmanlage room System,Haus
attr Alarmanlage stateFormat EG: Modus_Nacht | Info: Modus_Abwesend | Status: Alarm_Status | GSM: GSM_Status

#Aktoren Alarmanlage
define Alarmanlage_SmartHome HTTPMOD http://***USER***:***PASSWORD***@192.0.0.140/action/deviceListGet 30
attr Alarmanlage_SmartHome userattr getEncode readingEncode
attr Alarmanlage_SmartHome enableControlSet 1
attr Alarmanlage_SmartHome event-on-change-reading .*
attr Alarmanlage_SmartHome extractAllJSON 1
attr Alarmanlage_SmartHome getEncode UTF-8
attr Alarmanlage_SmartHome icon security
attr Alarmanlage_SmartHome preProcessRegex s/\"rssi\"\: \"\D*\t/\"rssi\"\: \"/g
attr Alarmanlage_SmartHome readingEncode UTF-8
attr Alarmanlage_SmartHome room System
attr Alarmanlage_SmartHome stateFormat lastReading


Schau mal, wie weit Du damit kommst. Bei den Autoren musst Du eine nicht Standard-konforme JSON-Implementierung von Lupus Electronics fixen, bevor Du das extractAllJSON durchführen kannst. Dafür gibt es die Option preProcessRegex.

is2late

#2
Hi,

ich habe zu Übungszwecken das Listing von Rudibarani (6.1.19) nachvollzogen. Meine Version der Lupusec ist die XT3. Vielleicht ist es dem geschuldet, dass ich bei den Devices folgende Fehlermeldung bekomme:

error while parsing JSON data: character encountered while parsing JSON string, at character Offset 244 (before "\t9",  \n"resp_mode":...") at (eval 4311) line 1.
Der Hinweis auf den Fehler scheint ja konkret; dennoch weiß ich leider nicht, wo genau ich suchen soll.

Ohnehin verstehe ich nicht, wieso der Wert "rssi" (der scheinbar die Verbindungsqualität darstellt) erhoben wird; mE wäre eher "Status_ex" für den Öffnungsstatus des Kontaktes interessant. Den würde ich dann so filtern:

\"status_ex\"\: \"\d\"    - was nach dem Regex-Tester korrekt zu sein scheint, aber ebenfalls zu einer Fehlermeldung führt, vermutlich/evtl, weil der PreProcess dabei unter den Tisch fällt. Und der soll ja lt Rudibarani erforderlich sein
ZitatBei den Aktoren musst Du eine nicht Standard-konforme JSON-Implementierung von Lupus Electronics fixen, bevor Du das extractAllJSON durchführen kannst.

Per HTTPMOD bekomme ich Folgendes:
"sid": "RF:01256630", "su": 1, "alarm_status": "", "status_ex": "0", "hue": "-1", "sat": "-1", "ctemp": "-1", "hue_cmode": "-1", "hue_cie_x": "-1", "hue_cie_y": "-1", "hue_color_cap": "0", "nuki": "-1", "shutter_turn": 0,"status": ""},
{"area": 1, "zone": 26, "type": 4, "type_f": "{D_TYPE_4}", "name": "Kellereingang",
"cond": "", "cond_ok": "1", "battery": "", "battery_ok": "1",
"tamper": "", "tamper_ok": "1", "bypass": 0, "rssi": "{WEB_MSG_STRONG} 7",
"resp_mode": [0,1,1,3,1,0], "ammeter": "0", "ver": "",
"bypass_tamper": 0,


Weiß ein Kundiger Rat?
LG


Pi4, Tahoma Jalousien, Hue, Echo, Sonos, Lupusec XT3, FritzBox

Rudibarani

Hallo Ingo,

ich habe bei mir auch die XT3 und ich denke, Dein Fehler wird an dem gleichen Problem hängen, wie anfangs bei mir. Lupusec baut in die JSON-Datei zwischen der geschweiften Klammer und der Zahl für die Batteriestärke ({WEB_MSG_STRONG} 7) ein "Tab"-Zeichen ein. Das ist aber nicht Teil der JSON-Definition und führt beim auslesen zu einer Fehlermeldung.

Der Maintainer von HTTPMOD hat damals netterweise gleich eine Lösung für mich implementieren können: preProcessRegex. Damit erfolgt eine Zeichenersetzung im JSON, bevor es an den Parser übergeben wird. Aus dem Tab wird mit folgendem Code einfach ein Leerzeichen und der Parser hat kein Problem mehr:

attr Alarmanlage_SmartHome preProcessRegex s/\"rssi\"\: \"\D*\t/\"rssi\"\: \"/g


Als Tipp für das weitere Vorgehen:

Ich habe mir für jeden Sensor folgendes Device zur Info angelegt. Die Zahl (hier 01) kann sich leider jedes Mal ändern, wenn neue Geräte angelernt werden! Das ist ziemlich nervig, da man dann die Devices in FHEM alle manuell nachziehen muss. Aber so bekommt man wenigstens mit, dass sich die Zuordnung geändert hat. Das ließe sich lösen, wenn man das Gerät nicht mehr über die Position im JSON anspricht (daher die Nummer), sondern über die eindeutige ID des Sensors - aber dafür müsste man ein ordentliches Modul programmieren.

define Alarm_Haustuer readingsGroup Alarmanlage_SmartHome:senrows_01 (.*_ok|.*_name|.*status_ex|.*bypass.*|.*rssi|.*sid|.*type|.*area)
attr Alarm_Haustuer group Alarmanlage
attr Alarm_Haustuer room Flur


Die einzelnen Sensoren habe ich dann so in FHEM eingebunden:
define Fenster_Bad_gekippt readingsProxy Alarmanlage_SmartHome:senrows_16_status_ex
attr Fenster_Bad_gekippt userattr struct struct_map structexclude
attr Fenster_Bad_gekippt devStateIcon on:fts_window_1w_tilt@on off:fts_window_1w
attr Fenster_Bad_gekippt group Fenster
attr Fenster_Bad_gekippt icon fts_window_1w_tilt
attr Fenster_Bad_gekippt room Badezimmer
attr Fenster_Bad_gekippt valueFn {($VALUE eq "0")?"off":"on"}


Alle Daten (z.B. auch der Batteriestatus) werden so alle 30 Sekunden von der Alarmanlage aktualisiert. Damit Öffnungen des Fenster direkt gemeldet werden, musst Du für beide Zustände (auf und zu) in der Alarmanlage eine Smarthome-Regel hinterlegen.
Bedingung: Türkontakt Badezimmer offen
Zeitplan: Immer
Aktion: Aktion-URL
http://192.0.0.95:8088/fhem?fwcsrf=XXXXX&cmd=set%20Fenster_Bad_gekippt%20on


Damit das klappt, musst Du in FHEM einen entsprechenden Zugang freischalten, da FHEM bei Dir ja hoffentlich über Benutzer & Passwort geschützt ist.
#WebAccess für die Alarmanlage
define WEBapi FHEMWEB 8088 global
attr WEBapi alias WEBapi (8088)
attr WEBapi csrfToken XXXXX   <--- Hier einen csrfToken vergeben, der auch in die Aktion-URL kommt
attr WEBapi icon it_internet
attr WEBapi room System


Wichtig:
FHEM ist damit leider über diese zweite Webseite intern ohne Passwort zu erreichen. Damit da nicht jemand anderes so leicht rumspielen kann, habe ich zumindest über folgende Funktion alle Bedienelemente ausgeblendet (alles ohne Leerzeichen per Komma getrennt listen, was in Deinem FHEM als Raum oder Menüpunkt angelegt ist):
attr WEBapi hiddenroom Save config,Tablet-UI,Aussen,Badezimmer,Büro,Changelog,CUL_HM,Heizungssteuerung,Dachboden,Dienste,Esszimmer,FBDECT,HUEDevice,Haus,Hauswirtschaftsraum,Homekit,Kinderzimmer1,Kinderzimmer2,Küche,Keller,Schlafzimmer,System,Residents,Multimedia,Gästezimmer,Treppenhaus,Sonos,Serverraum,Unsorted,WC,Wintergarten,Wohnzimmer,Zeitsteuerung,Logfile,Commandref,Remote doc,Edit files,Select style,Event monitor,Update,Update Check,Neustart,Everything,input,save,motd,textInput,menuScrollArea

Falls hier jemand mitliest, der mehr Ahnung hat, bin ich auch für Hinweise dankbar, wie man FHEM hier noch besser wieder absichern kann! Im Body der HTML-Datei steht der csrfToken nämlich leider im Klartext drin.

Melde Dich gerne wenn Du weitere Fragen hast.

is2late

Hallo Rudibarani,

ganz herzlichen Dank für Deine ausführliche Antwort! Sie hat mir sehr geholfen, die Zusammenhänge zu verstehen.

Kurioserweise - da wir doch beide die XT3 haben - half der Code
Zitatattr Alarmanlage_SmartHome preProcessRegex s/\"rssi\"\: \"\D*\t/\"rssi\"\: \"/g
nicht weiter; es blieb bei der o.g Fehlermeldung und die Readings fehlten.
Amenomade gab mir dann den Tipp
ZitatWarum machst Du nicht einfach alle Tabs weg?
Code: [Auswählen]
s/\t//g

. Das hat funktioniert.

Ich finde auch, dass es nervig ist, wenn sich die Devicebezeichnung bei jedem neuen Device ändert/verschiebt.
Elektrikpe2 https://forum.fhem.de/index.php/topic,110379.0.html hat eine Lösung, die das vermeidet.
Oder liegt der Unterschied nur darin, dass dort nicht senrows_xx_name, sondern, direkt der Wert dieses Feldes (zB "CO-Melder") eingebunden ist?

Schönen Sonntag noch!
LG Ingo 

Pi4, Tahoma Jalousien, Hue, Echo, Sonos, Lupusec XT3, FritzBox

amenomade

Zitat von: Rudibarani am 25 April 2020, 23:48:00
Wichtig:
FHEM ist damit leider über diese zweite Webseite intern ohne Passwort zu erreichen. Damit da nicht jemand anderes so leicht rumspielen kann, habe ich zumindest über folgende Funktion alle Bedienelemente ausgeblendet (alles ohne Leerzeichen per Komma getrennt listen, was in Deinem FHEM als Raum oder Menüpunkt angelegt ist):
attr WEBapi hiddenroom Save config,Tablet-UI,Aussen,Badezimmer,Büro,Changelog,CUL_HM,Heizungssteuerung,Dachboden,Dienste,Esszimmer,FBDECT,HUEDevice,Haus,Hauswirtschaftsraum,Homekit,Kinderzimmer1,Kinderzimmer2,Küche,Keller,Schlafzimmer,System,Residents,Multimedia,Gästezimmer,Treppenhaus,Sonos,Serverraum,Unsorted,WC,Wintergarten,Wohnzimmer,Zeitsteuerung,Logfile,Commandref,Remote doc,Edit files,Select style,Event monitor,Update,Update Check,Neustart,Everything,input,save,motd,textInput,menuScrollArea

Falls hier jemand mitliest, der mehr Ahnung hat, bin ich auch für Hinweise dankbar, wie man FHEM hier noch besser wieder absichern kann! Im Body der HTML-Datei steht der csrfToken nämlich leider im Klartext drin.

Mit einem "allowed" Device kann man noch ein paar Dinge einschrängen. https://fhem.de/commandref_DE.html#allowed
In WEBapi kann man noch die IP Adressen einschränken

Es wäre auch interessant zu testen, ob in Aktion-URL etwas wie https://user:passwort@192.0.0.95:8088/fhem?fwcsrf=XXXXX&cmd=set%20Fenster_Bad_gekippt%20on akzeptiert wird.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Rudibarani

Zitat von: is2late am 26 April 2020, 15:14:33
Ich finde auch, dass es nervig ist, wenn sich die Devicebezeichnung bei jedem neuen Device ändert/verschiebt.
Elektrikpe2 https://forum.fhem.de/index.php/topic,110379.0.html hat eine Lösung, die das vermeidet.
Oder liegt der Unterschied nur darin, dass dort nicht senrows_xx_name, sondern, direkt der Wert dieses Feldes (zB "CO-Melder") eingebunden ist?

Hallo Ingo,

ich kombiniere bei mir quasi beide Lösungen. Der Weg von Elektrikpe2 bildet immer live den Status der Sensoren der Alarmanlage in FHEM ab. Das mache ich ja über die Automatisierung ebenfalls. Dabei aktualisiere ich mir aber keinen Dummy, sondern ein Reading, dass weitere Informationen - wie z.B. den Batteriestand des Sensors - ebenfalls in FHEM abbildet. Durch die Automatisierung von Seiten der Alarmanlage ist der Sensorstatus immer live, die weiteren Daten bis zur nächsten Aktualisierung via HTTPMOD verzögert.

Wegen dem PreProcessRegex: wenn das bei Dir so geht, prima. Klar hätte ich auch einfach alle Tabs löschen können, da die in dem JSON ja sowieso nichts zu suchen haben. Keine Ahnung, warum ich das damals so kompliziert gemacht habe...

Viele Grüße!

Rudibarani

Zitat von: amenomade am 26 April 2020, 19:32:35
Mit einem "allowed" Device kann man noch ein paar Dinge einschrängen. https://fhem.de/commandref_DE.html#allowed
In WEBapi kann man noch die IP Adressen einschränken

Es wäre auch interessant zu testen, ob in Aktion-URL etwas wie https://user:passwort@192.0.0.95:8088/fhem?fwcsrf=XXXXX&cmd=set%20Fenster_Bad_gekippt%20on akzeptiert wird.

Vielen Dank für den Hinweis. Ich werde das mal ausprobieren und schauen, ob mit einer IP-Beschränkung der CSRF-Token-Zugang weiter funktioniert. Das wäre genau das, was ich gerne erreichen würde!

Ich habe übrigens on der Firma Lupusec mal die vollständige API-Beschreibung geschickt bekommen. Wenn ihr Lust habt, könnten wir gerne mal versuchen nicht nur den Status der Alarmanlage auszulesen, sondern diese auch zu steuern. Damit habe ich mich noch nicht befasst - fände ich aber klasse, wenn das ginge. Vielleicht landen wir dann doch mal irgendwann bei einem echten Lupsec-Modul  ;)

is2late

Hi Rudibarani,

hätte mir schon denken können, dass ich irgendeinen Vorteil der Direktabfrage der Devices nicht erkannt habe ;-)
ZitatDurch die Automatisierung von Seiten der Alarmanlage ist der Sensorstatus immer live, die weiteren Daten bis zur nächsten Aktualisierung via HTTPMOD verzögert.

Toll, dass Du die Api mit uns teilst. Ich würde gern einen Beitrag zu dem potentiellen Lupusec-Projekt liefern, aber zu mehr als Kaffeeholen (und allenfalls testen) langt es leider noch nicht  :-[

LG
Pi4, Tahoma Jalousien, Hue, Echo, Sonos, Lupusec XT3, FritzBox

amenomade

Die API ist ganz simpel. Zur Steuerung muss man nur POST Requests mit entspr. Parameter bauen. Das kann wohl HTTPMOD problemlos.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

is2late

Rudibarani, bitte noch eine Frage zur Problematik/Vermeidung der Änderung der Devicebezeichnung:

Wäre es denn nicht möglich, das Device statt über die JSON-Nummer über den Namen anzusprechen?
Dieser wird ja per deviceListGet auch mitgeliefert.

LG Ingo
Pi4, Tahoma Jalousien, Hue, Echo, Sonos, Lupusec XT3, FritzBox

Rudibarani

#11
Die JSON-Datei enthält viele repetitive Einträge, welche durch eine laufende Nummer getrennt werden, die bei parsen eingefügt wird. Von sich aus steht die da nicht drin.
Um sicher zu sein, dass die Zuordnungen sich nicht ändern, müsste man die Sensoren über ihre eindeutige ID von LupuSec ansprechen. Das ginge auch leicht, wenn man ein Modul hätte, das mit dem JSON gefüttert wird. Ohne gibt es leider nach meinem Kenntnisstand keine Alternative, welche alle Daten des JSON nutzt.
Du kannst natürlich die light-Variante nutzen und für die Sensoren jeweils Dummy anlegen, die Du über die Automation der XT3 aktualisierst. Dann siehst Du aber nicht alle Daten...


herrmannj

Evtl ist JsonMod hier eine Alternative

Rudibarani

Zitat von: herrmannj am 01 Mai 2020, 00:31:08
Evtl ist JsonMod hier eine Alternative
Hallo herrmannj,
vielen Dank - das ist ein interessantes Modul, dass ich noch nicht kannte! In diesem Fall wird es uns aber glaube ich nicht helfen. Das Problem entsteht dadurch, dass das JSON eine Reihe von repetitive Blöcken enthält, die wir gerne jeweils in ein Device über führen würden - mit den Werten als Readings.

HTTPMOD nummeriert diese Blöcke durch, so dass jedes Reading durch eine fortlaufende Nummer eine eindeutige Bezeichnung bekommt (siehe Anhang). Diese Nummer ändert sich aber leider, wenn ein neuer Sensor angelernt wird und das JSON mittendrin ein neues Element beinhaltet. Mit JsonMod kann ich mir alle eindeutigen IDs (sid) auslesen. Ich habe aber leider keinen Weg gesehen, diese ID zur eindeutigen Aggregation der Elemente auf der gleichen Ebene in einem Device zu nutzen. Gibt es so eine Funktion?

Für ein stabileres System würde es sonst auch erstmal reichen, wenn man die Daten aus dem JSON extrahieren könnte und dabei anstelle der zufälligen Nummer das System anweisen könnte, die jeweilige "sid" als Identifier einzusetzen. Aber auch dazu habe ich keinen Automatisierung gefunden. Für Hinweise wäre ich aber dankbar!
Viele Grüße!

rudolfkoenig

ZitatFür ein stabileres System würde es sonst auch erstmal reichen, wenn man die Daten aus dem JSON extrahieren könnte und dabei anstelle der zufälligen Nummer das System anweisen könnte, die jeweilige "sid" als Identifier einzusetzen. Aber auch dazu habe ich keinen Automatisierung gefunden. Für Hinweise wäre ich aber dankbar!
Mit json2nameValue (bzw. json2reading) und hashKeyRename kann man aus dem o.g. JSON folgende Readings produzieren:
fhem> define d dummy
fhem> { json2reading($defs{d}, `cat lupus.json`, undef, undef, 'hashKeyRename($ret, "(senrows_.*)_sid:(.*)", "(senrows_[^_]*)")') }
fhem> l d
Internals:
   CFGFN     
   FUUID      5eafd69f-f33f-c296-8436-2b9ea312c9771262
   NAME       d
   NR         18
   STATE      ???
   TYPE       dummy
   READINGS:
     2020-05-04 10:47:49   RF_0073ed70_alarm_status
     2020-05-04 10:47:49   RF_0073ed70_ammeter 0
     2020-05-04 10:47:49   RF_0073ed70_area 1
     2020-05-04 10:47:49   RF_0073ed70_battery
     2020-05-04 10:47:49   RF_0073ed70_battery_ok 1
     2020-05-04 10:47:49   RF_0073ed70_bypass 0
     2020-05-04 10:47:49   RF_0073ed70_bypass_tamper 0
     2020-05-04 10:47:49   RF_0073ed70_cond
     2020-05-04 10:47:49   RF_0073ed70_cond_ok 1
     2020-05-04 10:47:49   RF_0073ed70_hue -1
     2020-05-04 10:47:49   RF_0073ed70_name Eingang
     2020-05-04 10:47:49   RF_0073ed70_resp_mode_1 0
     2020-05-04 10:47:49   RF_0073ed70_resp_mode_2 5
     2020-05-04 10:47:49   RF_0073ed70_resp_mode_3 5
     2020-05-04 10:47:49   RF_0073ed70_resp_mode_4 5
     2020-05-04 10:47:49   RF_0073ed70_resp_mode_5 5
     2020-05-04 10:47:49   RF_0073ed70_rssi {WEB_MSG_STRONG} 9
     2020-05-04 10:47:49   RF_0073ed70_sat -1
     2020-05-04 10:47:49   RF_0073ed70_sid RF:0073ed70
     2020-05-04 10:47:49   RF_0073ed70_status
     2020-05-04 10:47:49   RF_0073ed70_status_ex 0
     2020-05-04 10:47:49   RF_0073ed70_su  0
     2020-05-04 10:47:49   RF_0073ed70_tamper
     2020-05-04 10:47:49   RF_0073ed70_tamper_ok 1
     2020-05-04 10:47:49   RF_0073ed70_type 37
     2020-05-04 10:47:49   RF_0073ed70_type_f {D_TYPE_37}
     2020-05-04 10:47:49   RF_0073ed70_ver
     2020-05-04 10:47:49   RF_0073ed70_zone 1
     2020-05-04 10:47:49   RF_04435330_alarm_status
     2020-05-04 10:47:49   RF_04435330_ammeter 0
     2020-05-04 10:47:49   RF_04435330_area 2
     2020-05-04 10:47:49   RF_04435330_battery
     2020-05-04 10:47:49   RF_04435330_battery_ok 1
     2020-05-04 10:47:49   RF_04435330_bypass 0
     2020-05-04 10:47:49   RF_04435330_bypass_tamper 0
     2020-05-04 10:47:49   RF_04435330_cond
     2020-05-04 10:47:49   RF_04435330_cond_ok 1
     2020-05-04 10:47:49   RF_04435330_hue -1
     2020-05-04 10:47:49   RF_04435330_name BM Treppenhaus
     2020-05-04 10:47:49   RF_04435330_resp_mode_1 0
     2020-05-04 10:47:49   RF_04435330_resp_mode_2 0
     2020-05-04 10:47:49   RF_04435330_resp_mode_3 0
     2020-05-04 10:47:49   RF_04435330_resp_mode_4 0
     2020-05-04 10:47:49   RF_04435330_resp_mode_5 0
     2020-05-04 10:47:49   RF_04435330_rssi {WEB_MSG_STRONG} 9
     2020-05-04 10:47:49   RF_04435330_sat -1
     2020-05-04 10:47:49   RF_04435330_sid RF:04435330
     2020-05-04 10:47:49   RF_04435330_status
     2020-05-04 10:47:49   RF_04435330_status_ex 0
     2020-05-04 10:47:49   RF_04435330_su  1
     2020-05-04 10:47:49   RF_04435330_tamper
     2020-05-04 10:47:49   RF_04435330_tamper_ok 1
     2020-05-04 10:47:49   RF_04435330_type 9
     2020-05-04 10:47:49   RF_04435330_type_f {D_TYPE_9}
     2020-05-04 10:47:49   RF_04435330_ver
     2020-05-04 10:47:49   RF_04435330_zone 1
     2020-05-04 10:47:49   RF_04993310_alarm_status
     2020-05-04 10:47:49   RF_04993310_ammeter 0
     2020-05-04 10:47:49   RF_04993310_area 1
     2020-05-04 10:47:49   RF_04993310_battery
     2020-05-04 10:47:49   RF_04993310_battery_ok 1
     2020-05-04 10:47:49   RF_04993310_bypass 0
     2020-05-04 10:47:49   RF_04993310_bypass_tamper 0
     2020-05-04 10:47:49   RF_04993310_cond
     2020-05-04 10:47:49   RF_04993310_cond_ok 1
     2020-05-04 10:47:49   RF_04993310_hue -1
     2020-05-04 10:47:49   RF_04993310_name Wohnungstür
     2020-05-04 10:47:49   RF_04993310_resp_mode_1 3
     2020-05-04 10:47:49   RF_04993310_resp_mode_2 1
     2020-05-04 10:47:49   RF_04993310_resp_mode_3 1
     2020-05-04 10:47:49   RF_04993310_resp_mode_4 1
     2020-05-04 10:47:49   RF_04993310_resp_mode_5 1
     2020-05-04 10:47:49   RF_04993310_rssi {WEB_MSG_STRONG} 9
     2020-05-04 10:47:49   RF_04993310_sat -1
     2020-05-04 10:47:49   RF_04993310_sid RF:04993310
     2020-05-04 10:47:49   RF_04993310_status {WEB_MSG_DC_CLOSE}
     2020-05-04 10:47:49   RF_04993310_status_ex 0
     2020-05-04 10:47:49   RF_04993310_su  1
     2020-05-04 10:47:49   RF_04993310_tamper
     2020-05-04 10:47:49   RF_04993310_tamper_ok 1
     2020-05-04 10:47:49   RF_04993310_type 4
     2020-05-04 10:47:49   RF_04993310_type_f {D_TYPE_4}
     2020-05-04 10:47:49   RF_04993310_ver
     2020-05-04 10:47:49   RF_04993310_zone 2
Attributes:



Wie man sowas in HTTPMOD einbaut, kann ich nicht sagen, da ich HTTPMOD nicht wirklich kenne.

Hat Lupus eine MQTT Schnittstelle ? :)