BSB-LAN über URL-Kommandos auslesen

Joey

Hallo,
ich habe versucht, ein scripted device anzulegen. Die Aufgabe ist, einen bestimmten Temperaturwert aus meiner Heizung auszulesen und in dS zur Verfügung zu stellen. Im Browser funktioniert das einfach:
Das URL-Kommando http://bsb-lan.local/JQ=8830 liefert folgenden json-output:

{
  "8830": {
    "name": "Trinkwassertemperatur-Istwert Oben (B3)",
    "dataType_name": "TEMP",
    "dataType_family": "VALS",
    "destination": 0,
    "error": 0,
    "value": "46.2",
    "desc": "",
    "payload": "000B8D",
    "precision": 0.1,
    "dataType": 0,
    "readwrite": 1,
    "unit": "°C"
  }
}

Ich habe mich an verschiedenen Beispielen orientiert, habe es aber nicht fertiggebracht, den Wert zurückzugeben. Ich habe es u.a. mit folgender init-message und script versucht:

{
  'message':'init',
  'protocol':'json',
  'name':'TW-temp', /* initialer Name */
  'sensors':[
    /* sensortype1 = Temperatur, updateinterval = 30 = zweimal ausgelesen pro Minute */
    {'sensortype':1,'usage':1, 'group':3, 'hardwarename':'TW_temp','min':0,'max':100,'resolution':0.1, 'updateinterval':30}
  ]
}

var url_tw_temp = "http://bsb-lan.local/JQ=8830"

// alle 30 Sekunden:
on (every(30)) {
  var msg = {'message':'sensors', 'index':0 }
  
    var ans = json(geturl(url_tw_temp, 10))
    //log (ans)
    msg.value = ans.value

    message(msg)
}
return true

Ich denke, mein Problem ist, dass ich Javascript nicht kenne und mir der Zusammenhang zwischen der Init-Sequenz und dem script nicht klar geworden ist. Dadurch verstehe ich in all den Beschreibungen der sehr umfangreichen Dokumentation die Zusammenhänge nicht. Ich habe ja schon die Beispiele ausprobiert und sie laufen auch, aber mein eigenes Beispiel habe ich nicht auf die Pfanne bekommen. Ein wenig Nachhilfe wäre sehr nett!

Viele Grüsse, Joey

luz

Hallo @Joey,

das sieht alles soweit gut aus.

Die Init-Message ist kein Code, nur eine Beschreibung der Eigenschaften des Geräts (Ausgang oder nicht, wieviele und welche Sensoren, Eingänge und Taster)

Der Zusammenhang zum Script ist nur, dass je nach dem, was die Init-Message enhält, die entsprechenden Sensoren oder Eingänge, Taster "bespielt" werden müssen.

In diesem Fall gibt es nur einen Sensor, deshalb index=0 in { 'message':'sensors', 'index':0 }). Hätte es einen zweiten Sensor, wäre es dann 'index':1 etc.

Was aber vermutlich das Problem ist: In dieser Heizungsantwort ist ja "value" nicht direkt auf der obersten Ebene, sondern in einem Objekt namens "8830" verpackt.

Ich würde deshalb denken es müsste heissen:

    msg.value = ans['8830'].value

Ansonsten würde ich erst mal das geturl() in der p44script-IDE-Konsole ausprobieren, ob das Resultat überhaupt da ankommt.

Joey

Hi Luz,
da sind offenbar mehrere Probleme. Zuerst: "Host not found". Beide Geräte beziehen ihre IP vom selben Router und hängen an demselben Switch: 192.168.188.5 und 192.168.188.191. Wenn ich im Script den Hostnamen durch die IP ersetze, ist zumindest der "Host not found error" weg. Der Rechner, ebenfalls DHCP (192.168.188.233) kann den Hostnamen auflösen, P44 nicht. Warum? Sollten die nicht den gleichen DNS per DHCP kommuniziert bekommen? P44 zeigt leider unter "edit network settings" in allen Feldern, auch der IP, nur 0.0.0.0 an, wenn DHCP aktiviert ist, so dass mir nicht klar ist, ob da überhaupt ein Nameserver hinterlegt ist. Vielleicht wäre es nützlich, die Werte in diesem Dialog ausgegraut anzuzeigen?
Das nächste Problem ist: Ich bekomme die json-Antwort und kann den Value extrahieren und loggen, allerdings stimmt offenbar etwas mit dem Rückgabewert nicht. Das muss ich aber erst selbst nochmal prüfen.
Wenn Du einen Hinweis hättest, wieso P44 den Hostname nicht auflösen kann, wäre mir erstmal geholfen. Natürlich könnte ich auch feste IP-Adressen vergeben, wenn das nicht zum Ziel führt, scheint mir aber weniger elegant. Vielen Dank im voraus!
Joey

luz

Joey Zuerst: "Host not found"

bsb-lan.local ist keine normale Domain, sondern ein DNS-SD hostname (aka Rendezvous, Bonjour, Avahi, ZeroConf). Diese werden nicht vom DNS-Server aufgelöst, der über DHCP bereitgestellt wird, deshalb nützt auch ein konfigurierter Nameserver nichts. Eine Plattform muss einen speziellen Service dafür haben, der die dezentrale Liste der Services im lokalen Netz unterhält und Abfragen ermöglicht. Auf dem Mac ist das der mDNSResponder, unter Linux avahi/systemd. Auf OpenWrt (die Platform der P44) ist kein DNS-SD-Resolver standardmässig eingebunden.

Der Grund ist, dass DNS-SD mehr kann, als nur die IP für einen Host-Namen zu finden. Das SD in DNS-SD steht für Service Discovery, die Idee ist, dass es damit möglich ist zu fragen: was gibt es an Geräten im lokalen Netz, die ein Webinterface haben? Oder Drucker die AirPrint können?

Dafür gibts in p44script seit 2.8.1 (besser noch: aktuelle Beta, es gab noch Bugfixes) die Funktion dnssdbrowse().

Damit lässt sich die Auflösung von http://bsb-lan.local/ bewerkstelligen:

var dnssd_infos = dnssdbrowse('_http._tcp', 'bsb-lan.local')
// Rückgabewert ist ein Array mit den Resultaten - nur eines wenn der Hostname angegeben wird wie hier
if (elements(dnssdinfos)>0) {
  // gefunden
  var dnssd_info = dnssdinfos[0] // erstes Element
  var url_tw_temp = dnssd_info.url // das ist die URL mit IP, Port und Pfad
}

// jetzt kann url_tw_temp in geturl, posturl, httprequest etc. verwendet werden

DNS-SD löst genauer auf als nur Name->IP, z.B. die Portnummer ist enthalten, der Pfad des Services auf dem Host, ein lesbarer Name etc.

Wenn Du in der p44script-IDE-Console eingibst dnssdbrowse('_http._tcp'), dann erhältst Du eine Liste aller im lokalen Netz verfügbaren Webinterfaces, normalerweise sind das Drucker, NAS, der dSS, und alle P44), so in der Art wie hier:

[
  {
    "hostaddress": "192.168.59.162",
    "hostname": "npie9d5e9.local",
    "interface": 2,
    "ipv6": false,
    "name": "HP Color LaserJet MFP M183fw (E9D5E9)",
    "port": 80,
    "txts": {
      "UUID": "564e4333-3330-3037-3536-040e3ce9d5e9"
    },
    "url": "http://192.168.59.162:80"
  },
  {
    "hostaddress": "192.168.59.222",
    "hostname": "p44dsbx50013630.local",
    "interface": 2,
    "ipv6": false,
    "name": "plan44.ch P44-DSB-X \"Mixwerk X\" #50013630",
    "port": 80,
    "txts": {
      "path": "/index.html"
    },
    "url": "http://192.168.59.222:80/index.html"
  },
  {
    "hostaddress": "192.168.59.211",
    "hostname": "dSS-LUZ-Testing.local",
    "interface": 2,
    "ipv6": false,
    "name": "dSS",
    "port": 80,
    "txts": {},
    "url": "http://192.168.59.211:80"
  },
  // ... 
]

Joey

luz Vielen Dank!

Das Ganze sieht jetzt so aus und funzt wunderbar:

var BSB_LAN_url = "BSB-LAN.local"
var BSB_LAN_TWtemp = "JQ=8830"

var dnssd_infos = dnssdbrowse('_http._tcp', BSB_LAN_url )
// Achtung, case-sensitive!  Rückgabewert ist ein Array mit den Resultaten - nur eines wenn der Hostname angegeben wird wie hier

if (elements(dnssd_infos)>0) {
  // gefunden
  var dnssd_info = dnssd_infos[0].url
  var url_tw_temp = dnssd_infos[0].url + '/' + BSB_LAN_TWtemp // das ist die URL mit IP, Port und Pfad
}

// alle 30 Sekunden:
on (every(30)) {
  var msg = {'message':'sensor', 'index':0 }
  try { 
    var ans = json(geturl(url_tw_temp, 10))
    msg.value = ans['8830'].value
    log(6, 'BSB-LAN TW-Temp: ', msg.value)
  }
  catch as e {
    log(4,'BSB-LAN nicht erreicht')
  }
  message(msg)
}
return true

Joey

Es ist ja leider nie so, dass man ein Problem löst und fortan geht alles ganz easy Daher kommt jetzt noch eine Anschlussfrage:
Mit obigem script kann ich eine Temperatur aus der Heizungsanlage auslesen und sie erscheint anstandslos im dSS. Ich habe sie einem Pseudo-Raum zugeordnet und sie wird wunderbar angezeigt, wenn auch mit etwas Verzögerung. Ich gedachte, sie für eine einfache Schaltentscheidung heranzuziehen. Da hatte ich die Rechnung ohne Digitalstrom gemacht: Während der Wert einwandfrei angezeigt wird (getesteter Wertebereich 40-62.5°C), kann man benutzerdefinierte Zustände auf Basis der Raumtemperatur nur für Temperaturen bis 58.8°C ableiten. dS hat an dieser Stelle den Wertebereich begrenzt: 58.8°C sind zuviel für ein Wohnzimmer und zu wenig für eine Sauna oder in meinem Falle eine Wassertemperatur. Nun denn, ich habe in P44 einen evaluated up/down button erzeugt, der bei einer Schwelltemperatur den Schaltzustand wechselt. Im P44 funktioniert das, überprüft durch save + check expressions. Der Schalter wird mit 2-Wege-Eingang (Eingangs-Modus "Klingeln") vom dSS-Konfigurator als Gerät angezeigt (kein Meter Name ist verzeichnet). Ich habe das Gerät dann ebenfalls in den Pseudoraum verschoben. Ich kann den Schalter für einen benutzerdefinierten Zustand oder als Schaltbedingung im Scene Responder verwenden, er erscheint unter Raumzustand "Licht ist eingeschaltet"/"Licht ist ausgeschaltet". Bis hierhin war ich euphorisch. ABER: der Wechsel des Status des P44-Evaluators hat nicht den gewünschten dS-Schaltvorgang ausgelöst.
Wer hat eine Idee, wo es jetzt wieder hängen könnte? Any help appreciated!

LG, Joey

luz

Joey Statt einen Up/Down-Button-Evaluator würde ich einen "binary input" Evaluator nehmen.

Solch ein digitales Steuersignal ist ein Standard-Fall im dSS (wo es lange Zeit ja nur die AKM-Inputs gab), und daher problemlos.

Up/down-Buttons führen eher ein Schattendasein, es gibt ja als native DS-Gerät meines Wissens nur den Schnurschalter, der tatsächlich up/down kann, und dann die P44-EnOcean-Wippen. Dass die als Eingang für dSS-Apps vielleicht nicht richtig tun, kann ich mir schon vorstellen (sie funktionieren einwandfrei als Raum/Bereichstaster).