[Frage] Fritz!DECT 200 API

[missenberger]

Guten Abend,

das ist ja mal ein sehr interessantes kleines Script. Danke für die Mühe.
Ich weiß... der Thread ist schon ein wenig älter. Weiß vielleicht trotzdem jemand, wie man das Script ändern muss, wenn man es nicht auf einem PHP-Server im Heimnetz betreiben möchte, sondern auf einem externen PHP-Webspace?

Ich habe grad versucht, anstatt fritz.box die aktuelle IP meiner Fritzbox im Quellcode zu hinterlegen. Klappt leider nicht. Würde mich über Tipps sehr freuen.

Viele Grüße
missenberger

 

[SnoopyDog]

Beim Comet DECT wurde die Antwort ein wenig aufgebohrt:

<device identifier="xxxx" id="18" functionbitmask="320" fwversion="03.66" manufacturer="AVM" productname="Comet DECT">
  <present>1</present>
  <name>Heizung Wohnzimmer Terasse</name>
  <temperature>
    <celsius>220</celsius>
    <offset>0</offset>
  </temperature>
  <hkr>
    <tist>44</tist>
    <tsoll>42</tsoll>
    <absenk>32</absenk>
    <komfort>42</komfort>
    <lock>0</lock>
    <devicelock>0</devicelock>
    <errorcode>0</errorcode>
    <batterylow>0</batterylow>
    <nextchange>
      <endperiod>1476046800</endperiod>
      <tchange>32</tchange>
    </nextchange>
  </hkr>
</device>

Neu sind

• lock
• devicelock
• errorcode
• batterylow
• nextchange

Die Werte unter "nextchange" kann ich derzeit noch nicht zuordnen. Batterylow ist ja schon mal ein Anfang; der Prozentwert wie er in der Box angezeigt wird, wäre natürlich zusätzlich auch ganz nett gewesen.

 

[JL3]

Könnte nextchange endperiod ein Timestamp sein, wann die nächste Werteaktualisierung stattfindet?
Und tchange auf welchen Temp-Wert geschaltet werden soll...

 

[SnoopyDog]

Stimmt Du hast Recht: tchange muß man durch zwei teilen und das ergibt die Absenktemperatur von 16°C, welche ich eingestellt habe.
Und endperiod ist ein Unix-Zeitstempel, wobei der im obigen Beispiel stehende den 09.10.2016 23:00:00 ergibt, also Beginn der Nachttemperatur bei mir.

Nachtrag: Ich als API-Designer hätte ja einen Wert, der den Batteriezustand beschreibt, nicht in dem Zweig <hkr> hinterlegt, denn der ist ja speziell für den Heizkörperregler zuständig. Besser paßt es eine Ebene höher, denn wer weiß, vielleicht bringt man ja doch noch ein gänzlich anderes SmartHome-Gerät mit Batterie auf den Markt?

 

[SnoopyDog]

Laut API-Beschreibung gibt es jetzt auch einen Ansatz, die Alarmsensoren, welche man per HAN-FUN anmeldet, im API zu reflektieren:

<alert>
  <state>0/1</state> - letzter übermittelter Alarmzustand (leer bei unbekannt oder Fehler)
</alert>

Schön wäre es, wenn es mindestens noch eine Batteriestandanzeige in Prozent (wie in der Web-Oberfläche) geben würde. Dies würde sowohl bei den HAN-FUN-Geräten als auch bei den Heizkörperreglern Sinn ergeben...

Nachtrag: Für einen Alarmsensor würde ich allerdings noch ein wenig mehr Informationen erwarten, wie z.B. den Zeitstempel, wann der aktuell aktive Alarm ausgelöst wurde und einen Zeitstempel, wann davor ein Alarm ausgelöst wurde (falls existent).

 

[SnoopyDog]

Bei den Heizkörperreglern wird jetzt (6.98) zusätzlich zu <BatteryLow/> auch in <Battery/> der Ladezustand der Batterien in Prozent übermittelt. BatteryLow hat sich im Übrigen bei mir nie geändert, auch wenn die Batterie nur noch 1% Ladezustand hatte.
Bei den DECT 200 Aktoren wird auch die Netzspannung in mV übermittelt. Keine Ahnung, ob das neu ist, aber mir ist es bisher nie aufgefallen.

Das XML für ein HAN FUN Gerät kann übrigens so aussehen:

<device identifier="xyz-abcd" id="2000" functionbitmask="8208" fwversion="0.0" manufacturer="0x2c3c" productname="HAN-FUN">
  <present>1</present>
  <name>Bewegungsmelder: Unit #0</name>
  <etsiunitinfo>
    <etsideviceid>406</etsideviceid>
    <unittype>515</unittype>
    <interfaces>32513,256</interfaces>
  </etsiunitinfo>
  <alert>
    <state>1</state>
  </alert>
</device>

 

[SnoopyDog]

Ich habe gerade einen neuen, noch nicht dokumentierten API-Aufruf entdeckt: Wenn man an den Webservice den Befehl

webservices/homeautoswitch.lua?switchcmd=getbasicdevicestats&sid=%x&ain=%s

sendet (Session ID und AIN des Geräts müssen übergeben werden), erhält man eine längliche Antwort in der Form

<devicestats>
  <temperature>
    <stats count="96" grid="900">260,260,....</stats>
  </temperature>
  <voltage>
    <stats count="360" grid="10">235736,235736,...</stats>
  </voltage>
  <power>
    <stats count="360" grid="10">0,0,0,2925,2925,...</stats>
  </power>
  <energy>
    <stats count="12" grid="2678400">5709,1089,0,0,0,0,0,0,0,0,0,0</stats>
    <stats count="31" grid="86400">291,532,520,532,...</stats>
  </energy>
</devicestats>

"grid" beschreibt das Zeitraster in Sekunden, in dem die Meßwerte erfaßt wurden; d.h. die Temperatur alle 15 Minuten, Spannung und Leistung alle 10 Sekunden usw.

 

[DDDanny]

Das XML für ein HAN FUN Gerät kann übrigens so aussehen:

Und so für einen Magenta Smarthome Tür/Fensterkontakt, optisch

<device identifier="xyz-abcd" id="2002" functionbitmask="8208" fwversion="0.0" manufacturer="0x0feb" productname="HAN-FUN">
  <present>1</present>
  <name>DC Magenta</name>
  <etsiunitinfo>
    <etsideviceid>interne Anmeldenummer</etsideviceid>
    <unittype>514</unittype>
    <interfaces>256</interfaces>
  </etsiunitinfo>
  <alert>
    <state>1</state>
  </alert>
</device>

alert 0 -> zu // 1 -> auf

Unit:
514 Tür/Fensterkontakt
515 dann wohl ein Motion Sensor

Interfaces - keine Ahnung, der FB wohl egal... vermute mal, dass IF 256 für Sensor -> Alert steht
(hab bei der ULE - Alliance leider noch keine Specs gefunden bzgl unit type und/oder interfaces )

 

[almisoft]

Das ist ja ein erfreulicher Zufall. Ich baue gerade eine Anzeige der Temperatur- und Energieverläufe in BoxToGo ein

Die Zustände von Fenster- und Türkontakten sind in der Betaversion 3.0.9 bereits eingebaut. Es fehlen aber noch ein paar Gerätetypen.

Vielen Dank für deine Infos.

Die Betaversion kann von http://beta.boxtogo.de geladen werden.

Gesendet von meinem SM-G930F mit Tapatalk

 

[DDDanny]

fyi: panasonic manufacturer id ist
leider haben meine 5 Stk. Panasonic KX-HNS103 EX W
Water Sensor Panasonic

wohl eine zu alte FW
1x lässt sich gar nicht verbinden :-(;
4 Stk. melden sich zwar an, aber hören nach der "erfolgreich verbunden" Meldung der FB (7490 [gw 6.93] + 7390) nicht auf zu blinken und daher werden wohl keine Funktionen erkannt.
Geräte verlieren nach FB neustart dann auch den Connect *grml*
Hoffe mal, dass Panasonic mir die hier (in Hamburg) updaten kann.

... manufacturer="0x0512" productname="HAN-FUN"><present>1</present><name>HAN-FUN #1</name></device>

 

[SnoopyDog]

In einer der letzten Inhouse-Versionen sind noch zwei neue API-Aufrufe hinzugekommen:
* gettemplatelistinfos (braucht scheinbar nur die sid als Parameter)
* applytemplate (braucht sid und irgendeine andere id als Parameter)
Leider kann ich erst heute Abend den Debugger anschmeissen und nachschauen, was zumindest der erste Befehl liefert.

 

[SnoopyDog]

Also, der erste Befehl liefert bei mir eine leere Liste zurück und ohne Beschreibung seitens AVM kann ich derzeit auch nichts genaueres sagen..

 

[DDDanny]

Ich weiß zwar wie ich an die TR64 XML über Port 49000 komme (da habe ich die action nicht gefunden).

Aber wie macht man das für die HTTP/AHA API .../webservices/ ?
Die neuen API Befehle hast Du durch einen

extract

der Firmware identifiziert?
Oder ist das ein bestimmtes Script, welches man sich im Broweser angucken kann?
Habe jetzt ja mittlerweile 3 non-avm Sensorarten am Laufen, vll hat es damit was zu tun ;-)

 

[SnoopyDog]

Ich weiß nicht, ob es diese beiden Befehle schon vorher gab, aber in 7.08 finde ich noch "getahascript" und "setahascript". Um die aufrufen zu dürfen, muß man aber "userrights.BoxAdmin" besitzen...

 

[SnoopyDog]

AVM scheint auf mich "gehört" zu haben: Der Batteriestatus wird nun zusätzlich auch außerhalb des "hkr" Nodes zurückgeliefert und beim Türsensor wird nun ein Unix-Zeitstempel mitgeliefert, welcher angibt, wann sich der Status des Sensors zum letzten Mal geändert hat.