NEWS
IoBroker simple-api adapter, POST mit setbulk, Fehler oder kann nicht lesen
-
So, jetzt haben wirs … ich hab das nochmal komplett geändert nachdem ich das bisherige Konzept verstanden habe!
Es ändert sich für Deine Funktion leicht der aufruf!!
POST http://127.0.0.1:18183/setValueFromBody ... user=admin&...
bzw im Normalfall kein Fragezeichen und keine Parameter.
0.5.1 auf Github bitte testen!
-
bin wieder zu Hause und habe die neue Version getestet.
- setValueFromBody funktioniert bei mir
callback-Post http://192.168.200.110:8087/setValueFromBody/javascript.0.Nuki.Devices.NukiSL1.NukiBridgeResponse Body: {\"nukiId\": 123456789, \"state\": 3, \"stateName\": \"unlocked\", \"batteryCritical\": false}
- und set funktioniert auch
GET http://192.168.200.110:8087/set/javascript.0.alarm.Devices.Cams.Cam1.alarm_ack?value=true
-
Würde das Thema hier gerne nochmal aufgreifen. Komme mit den ganzen Beiträgen in diesem Forentopic leider nicht weiter da ich oft nur "Bahnhof" verstehe.
kann jemand Schritt für Schritt beschreiben wie ich den simple api Adapter mit Nuki genau nutze? Ich habe leider noch recht wenig Plan von APIs
Was muss ich alles Konfigurieren?
Ich nehme an die Steuerung und Statusabfrage erfolgt ausschließlich per Script, oder? Wie hat das Script auszusehen?
Objekte werden sicher nicht automatisch generiert, oder?
Ein paar Kleine Hilfestellungen mit Beispielen würden mich sicher schon etwas weiterbringen.
Danke für eure Hilfe!
-
Dann solltest du bitte ein paar mehr Infos geben. Ich kann beispielsweise mit "mit Nuki" nichts anfangen …
-
Moin eXTreMe,
hast Du Dir die Doku zum Adapter (auf Github) mal durchgelesen?
==> https://github.com/ioBroker/ioBroker.simple-api
Da ist sehr genau beschreiben, wie man über Webcommands (html) über den Adapter was alles machen kann:
-
Werte auslesen
-
Werte setzen (was auch eine Aktion auslösen kann, z.B. State auf true = Licht an)
Aber mehr Randinformationen sind immer gut.
Was genau hast Du vor?
Was hast Du bisher, mit welchem Erfolg, schon probiert?
Fehlermeldungen
Usw.
Gruß,
Eric
Von unterwegs getippert
-
-
Nuki ist ein Smart Lock, also ein fernsteuerbares Türschloss welches entweder direkt per bluetooth zwischen handy und schloss kommuniziert oder vom handy über internet an eine optional erhältliche bridge welche dann wiederum per bluetooth an das schloss funkt. hat man eine bridge so kann man auch im lokalen netz eine http api nutzen. https://nuki.io/de/
ja ich habe mir die doku zum adapter mehrmals durchgelesen aber leider nicht verstanden.
Also ich weiß über welche URL ich mir z.B. den Status des Türschlosses anzeigen lassen kann oder über welche URL ich das Schloss sperren oder öffnen kann. Das steht alles in der Nuki API gut erklärt: https://nuki.io/wp-content/uploads/2016 … I-v1.5.pdf
Das habe ich über meinen Browser durch aufruf der URL mit den jeweiligen Parametern getestet und klappt auch.
Was mir jedoch überhaupt nicht klar wird ist wie genau ich jetzt über iobroker das ganze einbinde um z.b. den status abzufragen, das schloss sperren oder öffnen zu lassen und die jewiligen antwortparameter die auf meine aktionen geantwortet werden in entsprechende datenpunkte in iobroker übernehme.
wie genau hat das javascript auszusehen?
kann mir das jemand an einem codebeispiel erklären?
Vielen Dank!
-
Hi,
Also simpleAPI ist dazu da um mit eigenen Skripten von Aussen auf ioBroker zuzugreifen.
Was Du eher brauchst ist wirklich ein JavaScript was mit deinem Türschloss kommuniziert.
Such mal im Forum nach "request", so heisst die nodejs Library um HTTP Requests (GET/POST u.ä.) zu machen. Das wäre Dein Ansatz.
Für ein Beispiel fehlt mir gerade die Zeit, sorry
-
Ich habe Nuki mit der WLAN-Bridge per Skript und VIS in Nutzung. Das ganze würde ich gerne in einen Adapter packen, aber da fehlt mir momentan die Zeit.
Ein paar Bemerkungen zu diesem Schloss und dem praktischen Einsatz bei mir: * * Ich nutze die angebotenen Möglichkeiten via Handy sehr sehr selten, stattdessen den Nuki FOB (Bluetooth-Sender).
* Für die Einbindung in mein LAN nutze ich die Bridge ohne Internetverbindung. Da Nuki den Zeitserver in der Bridge nicht konfigurierbar ausgelegt hat, haben die Logs dann leider keinen Zeitstempel. Warum will jeder Anbieter seine Nutzer entmündigen und "beschützen"? Ich hoffe, Nuki macht die WLAN-Bridge demnächst mal "voll" LAN-tauglich. * Das Schloss hat wie auch alle anderen vergleichbare Produkte keinen Sensor, um zu erkennen, ob die Tür geschlossen (eingeschnappt, in Schließposition) oder (etwas) offen ist. D. h., per App kann durchaus eine leicht offen stehende Tür "zugeschlossen" werden, was mir auch anfangs passiert ist, da der Schapper leicht verzögert nach dem Aufschließen freigegeben wird und die Tür dann u. U. nach dem vermeintlichen Schließen aus dem Türrahmen hervorsteht (hängt sicherlich von der Konstruktion der Tür und ggf. zusätzlichen Mechanismen ab). * Es fehlen einige Komfortfunktionen, wie z. B. zeitgesteuertes Zu- und Aufschließen in Abhängigkeit von Wochen- und Feiertagen (Wochentage-Zeitschaltung wird mit der letzten Version unterstützt) und der Anwesenheit (Während des Urlaubs bitte nicht aufschließen). * Jede Abfrage des Schlossstatus kostet Energie. Deshalb war die Implementierung des Callbacks in der Bridge ein großer Fortschritt. D. h., ich lasse mir via Callback Aktionen am Nuki „bestätigen“ und da kommt die Simple-API ins Spiel. * Zusätzlich löst bei mir jede Statusänderung des Türsensors (Subscription) eine Statusabfrage des Nuki aus. Ist laut Nuki der Türriegel ausgefahren und der Türsensor meldet offen, dann sollte das Skript einiges zu melden haben …
Beispiele:
Tür öffnen:
var action = 1; // öffnen // Parameter siehe Nuki-Bridge-API-Doku und Bsp. var sUrl = ‘http://’ + sServer + ‘:’ + sPort + ‘/lockAction?nukiId=’ + sNukiId + ‘&action=’ + action + ‘&token=’ + sToken; var request = require('request'); request(sUrl, function (error, response, body) { if(typeof response == ‘undefined’) { log(‘no response object!’); } else { // status only exist on valid response log(‘statusCode:’ + response.statusCode); if ((response) && !(error) && (response.statusCode == 200) { … } else { // Fehler .. } });
Callback
Per Skript trage ich in der Bridge eine callback-Methode ein, die bei Auslösung einer Nuki-Aktion von der Bridge nach der Beendigung der Aktion ausgeführt wird. D. h., die Callback-Methode wird als Bestätigung der Aktion genutzt.
var siobNukiStatus = ‘/setValueFromBody/’ + <id deines/datenpunktes/im/iobroker="">; // z. B. ‘/setValueFromBody/javascript.0.Nuki.devices.Nuki1.NukiBridgeResponse", var sUrl = ‘http://’ + sServer + ‘:’ + sPort + ‘/callback/add?url=’ + encodeURIComponent(‘http://’ + ioBrokerHostnameOrIP + ‘:’+ ioBrokerSimpleApiPort + siobNukiStatus) + ‘&token=’ + sToken; var request = require('request'); request(sUrl, function (error, response, body) { … });</id>
Löst du nun eine Aktion per Http-Request aus, sollte etwas später im Datenpunkt aus dem Callback in etwa folgendes stehen:
{\"nukiId\": 12345689, \"state\": 3, \"stateName\": \"unlocked\", \"batteryCritical\": false}
Was du dann über einen entsprechenden Subscriber auswerten kannst.
Hoffe, du kommst damit weiter.
-
Also simpleAPI ist dazu da um mit eigenen Skripten von Aussen auf ioBroker zuzugreifen. ` Vielen Dank für den Adapter, hat mir schon bei meiner ESP32 Bastelei sehr geholfen. Nutze dort setBulk, was sehr praktisch ist.
Jetzt sehe ich, daß es im "ioBroker Simple Web Adapter" ebenfalls die Möglichkeit gibt, eine (die?) simpleAPI anzukreuzen und zu nutzen. Dann wohl über Port 8082 statt 8087.
Ist das die gleiche (selbe?) simpleAPI oder etwas anderes? Was wird empfohlen?
-
Es ist "die" simpleapi … die wird als dependency beim web-adapter mit installiert und dann genutzt. Du hast nur nicht so einfach die mögöichkeit es unter nem anderen User laufen zu haben und sowas.
-
Vielen Dank für die Info.
Noch eine Frage zur Simple.API: welche Limitationen gelten bei setBulk hinsichtlich der Anzahl der Setzpunkte bzw. der Länge des zu übertragenden Strings?
Sind diese Limitationen im SimpleWeb Adapter die gleichen?
-
Es sind keine Limits implementiert … musst es mal austesten
-
Vielen Dank für die Antwort. Irgendwo in der Kette wird eine Limitation auftreten. Gut, ich bin gewarnt und werde das beachten, wenn das Datenaufkommen steigt. Derzeit wickle ich noch viel über die CCU/CUxD ab aber die ersten Gehversuche mit der Übertragung vom ESP32 zum ioBroker funktionieren dank dem simple-API und ich werde wahrscheinlich noch in diese Richtung expandieren.
-
Alternative ohne Limits ist immer die Nutzung von POST anstelle GET