Doorbird Fehler "Permissen Error"
Closed this issue · 27 comments
Wollte seit langen einmal den Doorbird-Adapter ans laufen bringen. Soweit läuft er auch, aber mir werden die State´s der Bilder nicht angezeigt. Hab nun einiges im Forum gelesen und ausprobiert, aber der Adapter scheint Probleme zu haben.
Anbei mal ein paar Screenshots des Fehlers und wie die States aussehen. Denn es wird keine Bild-URL angezeigt. Somit kann ich das nicht weiter verarbeiten.
Eventuell kann jemand helfen?
Da der Adapter Entwickler schon länger nichts mehr macht, wäre vielleicht eine Möglichkeit da, diesen gemeinsam zu bearbeiten?
Systeminformationen:
ioBroker
Plattform
linux
Betriebssystem
linux
Architektur
x64
CPUs
2
Geschwindigkeit
1895 MHz
Modell
Common KVM processor
RAM
7.61 GB
System-Betriebszeit
4 T. 23:18:14
Node.js
v14.18.2
NPM
6.14.15
Für mich sieht es so aus, als ob der verwendete Nutzer auf Doorbird-Seite nicht die erforderlichen Rechte hat, um einen Snapshot erstellen zu dürfen. Eventuell wurde das Berechtigungskonzept ja angepasst und eine neue Rolle eingeführt? Ich habe leider keine Doorbird hier um das zu testen.
Welche Rechte hast Du dem Nutzer denn in der App gegeben? Hast Du mal einen Screenshot davon?
Sorry, ist noch früh für mich 😄 Habe nur die Hälfte gelesen 😪 Scheinbar darf der ioBroker-Nutzer den State nicht schreiben. Bitte teile mal die Infos unter "Objektdaten" hier. Also das JSON von dem Objekt. Da sind auch die ACL enthalten.
{
"type": "state",
"common": {
"name": "JPG file",
"type": "file",
"read": true,
"write": false,
"desc": "Can be accessed from web server under http://ip:8082/state/doorbird.0.Doorbell.1.snapshot"
},
"native": {},
"from": "system.adapter.doorbird.0",
"user": "system.user.admin",
"ts": 1625148700724,
"_id": "doorbird.0.Doorbell.1.snapshot",
"acl": {
"object": 1636,
"state": 1636,
"owner": "system.user.admin",
"ownerGroup": "system.group.administrator"
},
"binary": true
}
Sorry, ist noch früh für mich 😄 Habe nur die Hälfte gelesen 😪 Scheinbar darf der ioBroker-Nutzer den State nicht schreiben. Bitte teile mal die Infos unter "Objektdaten" hier. Also das JSON von dem Objekt. Da sind auch die ACL enthalten.
So, hier auch mal meine Ausgaben, jeweils jetzt nur für den .Doorbell Datenpunkt.
Original Erstellung (nach Installation):
{ "type": "state", "common": { "name": "JPG file", "type": "file", "read": true, "write": false, "desc": "Can be accessed from web server under http://ip:8082/state/doorbird.0.Doorbell.1.snapshot" }, "native": {}, "from": "system.adapter.doorbird.0", "user": "system.user.admin", "ts": 1640212141388, "_id": "doorbird.0.Doorbell.1.snapshot", "acl": { "object": 1636, "state": 1636, "owner": "system.user.Quirin", "ownerGroup": "system.group.administrator" } }
Habe ich bereits so zum versuch abgeändert, mittels Expertenmodus:
{ "type": "state", "common": { "name": "JPG file", "type": "file", "read": true, "write": true, "desc": "Can be accessed from web server under http://ip:8082/state/doorbird.0.Doorbell.1.snapshot" }, "native": {}, "_id": "doorbird.0.Doorbell.1.snapshot", "acl": { "object": 1638, "state": 1638, "owner": "system.user.Quirin", "ownerGroup": "system.group.administrator" }, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1640136367441, "binary": true }
Zudem habe ich die Zugriffssteuerungsliste mittels dem Expertenmodus für die beiden States jeweils auf 666 gestellt, was aber auch keine Besserung bringt.
Aktuell
- Admin 5.2.2
- js.controller 3.3.22
Sorry, ist noch früh für mich 😄 Habe nur die Hälfte gelesen 😪 Scheinbar darf der ioBroker-Nutzer den State nicht schreiben. Bitte teile mal die Infos unter "Objektdaten" hier. Also das JSON von dem Objekt. Da sind auch die ACL enthalten.
So, hier auch mal meine Ausgaben, jeweils jetzt nur für den .Doorbell Datenpunkt.
Original Erstellung (nach Installation):
{ "type": "state", "common": { "name": "JPG file", "type": "file", "read": true, "write": false, "desc": "Can be accessed from web server under http://ip:8082/state/doorbird.0.Doorbell.1.snapshot" }, "native": {}, "from": "system.adapter.doorbird.0", "user": "system.user.admin", "ts": 1640212141388, "_id": "doorbird.0.Doorbell.1.snapshot", "acl": { "object": 1636, "state": 1636, "owner": "system.user.Quirin", "ownerGroup": "system.group.administrator" } }
Habe ich bereits so zum versuch abgeändert, mittels Expertenmodus:
{ "type": "state", "common": { "name": "JPG file", "type": "file", "read": true, "write": true, "desc": "Can be accessed from web server under http://ip:8082/state/doorbird.0.Doorbell.1.snapshot" }, "native": {}, "_id": "doorbird.0.Doorbell.1.snapshot", "acl": { "object": 1638, "state": 1638, "owner": "system.user.Quirin", "ownerGroup": "system.group.administrator" }, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1640136367441, "binary": true }
Zudem habe ich die Zugriffssteuerungsliste mittels dem Expertenmodus für die beiden States jeweils auf 666 gestellt, was aber auch keine Besserung bringt.
Aktuell
- Admin 5.2.2
- js.controller 3.3.22
Ja die Beiden Schritte habe ich exakt auch so ausprobiert aber ohne Erfolg. Sehr merkwürdig das der Adapter sich so verhält, ich befürchte das es was mit dem Admin 5.2.2 zu tun hat!
Sorry, ist noch früh für mich 😄 Habe nur die Hälfte gelesen 😪 Scheinbar darf der ioBroker-Nutzer den State nicht schreiben. Bitte teile mal die Infos unter "Objektdaten" hier. Also das JSON von dem Objekt. Da sind auch die ACL enthalten.
So, hier auch mal meine Ausgaben, jeweils jetzt nur für den .Doorbell Datenpunkt.
Original Erstellung (nach Installation):
{ "type": "state", "common": { "name": "JPG file", "type": "file", "read": true, "write": false, "desc": "Can be accessed from web server under http://ip:8082/state/doorbird.0.Doorbell.1.snapshot" }, "native": {}, "from": "system.adapter.doorbird.0", "user": "system.user.admin", "ts": 1640212141388, "_id": "doorbird.0.Doorbell.1.snapshot", "acl": { "object": 1636, "state": 1636, "owner": "system.user.Quirin", "ownerGroup": "system.group.administrator" } }
Habe ich bereits so zum versuch abgeändert, mittels Expertenmodus:
{ "type": "state", "common": { "name": "JPG file", "type": "file", "read": true, "write": true, "desc": "Can be accessed from web server under http://ip:8082/state/doorbird.0.Doorbell.1.snapshot" }, "native": {}, "_id": "doorbird.0.Doorbell.1.snapshot", "acl": { "object": 1638, "state": 1638, "owner": "system.user.Quirin", "ownerGroup": "system.group.administrator" }, "from": "system.adapter.admin.0", "user": "system.user.admin", "ts": 1640136367441, "binary": true }
Zudem habe ich die Zugriffssteuerungsliste mittels dem Expertenmodus für die beiden States jeweils auf 666 gestellt, was aber auch keine Besserung bringt.
Aktuell
- Admin 5.2.2
- js.controller 3.3.22
Ja die Beiden Schritte habe ich exakt auch so ausprobiert aber ohne Erfolg. Sehr merkwürdig das der Adapter sich so verhält, ich befürchte das es was mit dem Admin 5.2.2 zu tun hat!
Habe sogar mal die kompletten State-Rechte im ioBroker auf 666 geändert. Hatte auch nichts gebracht.
Eventuell liegt es daran, dass der Adapter nur bis Node 10 stable war?
Aktuell habe ich Node 14.
Neue Erkenntnis, wenn man per Console die datei "doorbird.0.snap.jpg" unter /opt/iobroker/iobroker-data per chmod auf 676 setzt, wird zumindest einmal hier die Datei gespeichert beim Klingeln. Somit kann man mit folgendem Befehl "http://ip:8082/state/doorbird.0.Doorbell.1.snapshot" die Datei im Browser abrufen. Was uns aber immer noch nicht an das Ziel bringt.
In den Objekten steht aber immer noch [undef]
ich befürchte das es was mit dem Admin 5.2.2 zu tun hat!
Warum sollte es etwas mit dem Admin zu tun haben? Wenn der Doorbird-Adapter mit dem js-controller spricht (und den State anpassen möchte), dann hat der Admin damit doch gar nichts zu tun?
Am Ende geht es ja um diese Stelle:
So richtig kann ich mir das nicht erklären. Dort wird kein Benutzer mitgegeben. Also wird der Standard-Benutzer system.user.admin
genommen. Und der ist ja in der Gruppe system.group.administrator
welche alle Rechte hat (und welche man nichtmal anpassen kann).
Ich könnte mir vorstellen, dass das ein Bug in den aktuellen js-controller
Versionen ist. Aber das müsste man natürlich testen. Hast Du vor kurzem ein js-controller
update gemacht?
ich befürchte das es was mit dem Admin 5.2.2 zu tun hat!
Warum sollte es etwas mit dem Admin zu tun haben? Wenn der Doorbird-Adapter mit dem js-controller spricht (und den State anpassen möchte), dann hat der Admin damit doch gar nichts zu tun?
Am Ende geht es ja um diese Stelle:
So richtig kann ich mir das nicht erklären. Dort wird kein Benutzer mitgegeben. Also wird der Standard-Benutzer
system.user.admin
genommen. Und der ist ja in der Gruppesystem.group.administrator
welche alle Rechte hat (und welche man nichtmal anpassen kann).Ich könnte mir vorstellen, dass das ein Bug in den aktuellen
js-controller
Versionen ist. Aber das müsste man natürlich testen. Hast Du vor kurzem einjs-controller
update gemacht?
Also ich hatte glaub ich gestern oder vorgestern ein Update des js-controller gemacht. Wobei das Problem auch schon in der Version davor und in der vor-vor Version bestand ;)
Das Problen besteht seid ende August! Dort hat sich beim ioBroker irgendewas getan durch updates das es zu diesem Phänomen kommt.
das Problem besteht schon viel länger. Ich hole mir die Bilder mittlerweile per Blockly!
das Problem besteht schon viel länger. Ich hole mir die Bilder mittlerweile per Blockly!
Oh das hört sich gut an.
Würdest du uns den Code für dein Blockly hier zur Verfügung stellen ?
Danke und Frohe Weinachten!
für Klingel
const idklingel = ["doorbird.0.Doorbell.102.trigger"];
var sperre = false; //verhindert das doppeltes Drücken das Script stoppt
var timeout1, timeout2, timeout3, timeout4, timeout5, timeout6, timeout7, timeout8, timeout9, timeout10, timeout11;
var fs = require('fs');
on({id: idklingel, change: "any"}, function (obj) {
if(!sperre) {
sperre = true;
// Speichert das erste Bild bei Klingeln
exec('wget --output-document /tmp/nega1.jpg 'http://User:Password@10.0.1.84/bha-api/image.cgi\'');
// Nach dem ersten Bild wird nach 2000ms das nächste Bild gespeichert
// timeout1 = setTimeout(function () {
//
// exec('wget --output-document /tmp/nega2.jpg \'http://User:Password@10.0.1.84/bha-api/image.cgi\'');
//
// }, 2000);
// Nach dem zweiten Bild wird nach 2000ms das nächste Bild gespeichert
// timeout2 = setTimeout(function () {
//
// exec('wget --output-document /tmp/nega3.jpg \'http://User:Password@10.0.1.84/bha-api/image.cgi\'');
//
// }, 4000);
// Nach dem dritten Bild wird nach 2000ms das nächste Bild gespeichert
// timeout3 = setTimeout(function () {
//
// exec('wget --output-document /tmp/nega4.jpg \'http://User:Password@10.0.1.84/bha-api/image.cgi\'');
//
// }, 6000);
/*
// Telegram versenden
timeout4 = setTimeout(function(){
sendTo('telegram.0', {text: '/tmp/nega1.jpg', caption: 'Jemand klingelt an der Haustür !!!'});
//log ('__ Klingel-Bild wurde versendet __');
}, 10000);
timeout5 = setTimeout(function(){
sendTo('telegram.0', {text: '/tmp/nega2.jpg', caption: 'Jemand klingelt an der Haustür !!!'});
//log ('__ Klingel-Bild wurde versendet __');
}, 11000);
*/
}
timeout6 = setTimeout(function() {
sperre = false;
}, 5000); //Zeit für Klingelsperre 1.Zeile
// Bilder werden nach vis gespeichert
timeout7 = setTimeout(function () {
const bild1 = fs.readFileSync('/tmp/nega1.jpg');
writeFile('vis.0','/_temp/nega/nega1.jpg', bild1);
// const bild2 = fs.readFileSync('/tmp/nega2.jpg');
//
// writeFile('vis.0','/_temp/nega/nega2.jpg', bild2);
//
// const bild3 = fs.readFileSync('/tmp/nega3.jpg');
//
// writeFile('vis.0','/_temp/nega/nega3.jpg', bild3);
//
// const bild4 = fs.readFileSync('/tmp/nega4.jpg');
//
// writeFile('vis.0','/_temp/nega/nega4.jpg', bild4);
}, 20000);
});
für Bewegungsmelder
const idklingel = ["doorbird.0.Motion.trigger"];
var sperre = false; //verhindert das doppeltes Drücken das Script stoppt
var timeout1, timeout2, timeout3, timeout4, timeout5, timeout6, timeout7, timeout8, timeout9, timeout10, timeout11;
var fs = require('fs');
on({id: idklingel, change: "any"}, function (obj) {
if(!sperre) {
sperre = true;
// Speichert das erste Bild bei Klingeln
exec('wget --output-document /tmp/nega1.jpg 'http://User:Password@10.0.1.84/bha-api/image.cgi\'');
// Nach dem ersten Bild wird nach 2000ms das nächste Bild gespeichert
// timeout1 = setTimeout(function () {
//
// exec('wget --output-document /tmp/nega2.jpg \'http://User:Password@10.0.1.84/bha-api/image.cgi\'');
//
// }, 2000);
// Nach dem zweiten Bild wird nach 2000ms das nächste Bild gespeichert
// timeout2 = setTimeout(function () {
//
// exec('wget --output-document /tmp/nega3.jpg \'http://User:Password@10.0.1.84/bha-api/image.cgi\'');
//
// }, 4000);
// Nach dem dritten Bild wird nach 2000ms das nächste Bild gespeichert
// timeout3 = setTimeout(function () {
//
// exec('wget --output-document /tmp/nega4.jpg \'http://User:Password@10.0.1.84/bha-api/image.cgi\'');
//
// }, 6000);
/*
// Telegram versenden
timeout4 = setTimeout(function(){
sendTo('telegram.0', {text: '/tmp/nega1.jpg', caption: 'Jemand klingelt an der Haustür !!!'});
//log ('__ Klingel-Bild wurde versendet __');
}, 10000);
timeout5 = setTimeout(function(){
sendTo('telegram.0', {text: '/tmp/nega2.jpg', caption: 'Jemand klingelt an der Haustür !!!'});
//log ('__ Klingel-Bild wurde versendet __');
}, 11000);
*/
}
timeout6 = setTimeout(function() {
sperre = false;
}, 5000); //Zeit für Klingelsperre 1.Zeile
// Bilder werden nach vis gespeichert
timeout7 = setTimeout(function () {
const bild1 = fs.readFileSync('/tmp/nega1.jpg');
writeFile('vis.0','/_temp/nega/nega1.jpg', bild1);
// const bild2 = fs.readFileSync('/tmp/nega2.jpg');
//
// writeFile('vis.0','/_temp/nega/nega2.jpg', bild2);
//
// const bild3 = fs.readFileSync('/tmp/nega3.jpg');
//
// writeFile('vis.0','/_temp/nega/nega3.jpg', bild3);
//
// const bild4 = fs.readFileSync('/tmp/nega4.jpg');
//
// writeFile('vis.0','/_temp/nega/nega4.jpg', bild4);
}, 20000);
});
@GermanBluefox Hast Du eine Idee? Könnte das ein Bug im js-controller sein?
Ich glaube @GermanBluefox hat viel zu tun ;)
Gerade nochmal etwas weiter gesucht. Scheinbar wird das Thema mit js-controller 4.x gefixt. Zumindest gibt es ein Changelog-Eintrag dafür:
* (foxriver76) fixed permissionError on setBinaryState
Habe gestern den aktuellen js-controller 4.0.4 aufgespielt, den Adapter deaktiviert, Alle States gelöscht und den Adapter wieder aktiviert. Leider bleibt das Problem bestehen und im State wird wieder [undef] geschrieben.
Dass im State [undef] steht ist leider richtig. Die Daten liegen dann auch dort, nur der Admin kann das nicht darstellen. Siehe ioBroker/ioBroker.admin#1281
Hab alles gestern einmal aktualisiert. Nun steht zumindest einmal [file] drin. Jedoch wenn man drauf drückt, erscheint nichts
Wie gesagt, das ist ein Admin-Thema. Was soll denn erscheinen?
Da könnte ja alles mögliche drin gespeichert sein. Das kann der Admin unmöglich alles abbilden.
Also würde ich sagen dass das nun richtig funktioniert und man die Daten weiter verarbeiten kann. Der ursprüngliche Issue mit den Berechtigungen ist ja gefixt.
Also dann könnte ich weiter machen, aber leider ist die Dateigröße bei 0 kb. Also nichts vorhanden.
Wie hast Du den Binary State denn ausgelesen?
So langsam habe ich hier den Faden verloren.
- was genau machst Du eigentlich / was geht nicht mehr?
- was hat das mit diesem Issue (permission error) zu tun?
- was hat Filezilla damit zu tun?
Du hast Recht, hat nichts mehr mit dem hier genannten Issu zu tun. Ich eröffne ein neues
Dann kann ja hier geschlossen werden? 😄