Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Thomas Braun]

@gifu

Ausgaben zeigen.

[Gifu]

@thomas-braun

Yes, sir.

gero@servervm2:~$ uname -m && type -P nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs
x86_64
/usr/bin/nodejs
/usr/bin/node
/usr/bin/npm
v16.16.0
v16.16.0
8.11.0
gero
/home/gero
OK:1 http://deb.debian.org/debian bullseye InRelease
OK:2 http://deb.debian.org/debian-security bullseye-security InRelease
OK:3 http://deb.debian.org/debian bullseye-updates InRelease
OK:4 https://deb.nodesource.com/node_16.x bullseye InRelease
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Alle Pakete sind aktuell.
nodejs:
  Installiert:           16.16.0-deb-1nodesource1
  Installationskandidat: 16.16.0-deb-1nodesource1
  Versionstabelle:
 *** 16.16.0-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_16.x bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
     12.22.12~dfsg-1~deb11u1 500
        500 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages
     12.22.5~dfsg-2~11u1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages

[Gifu]

Kurzes Update:
Ich habe eine neue VM erstellt und ioBroker unter Debian11 frisch installiert und nur den Zigbee Adapter hinzugefügt. Die Lösung war trivial und habe diese schon in meiner produktiven ioBroker VM angewendet. Ich musste in den Adaptereinstellungen nur den Kanal einmalig von 11 auf 13 ändern, damit der Adapter startet. Danach konnte ich wieder auf 11 wechseln.

Warum das so ist, erschließt mir nicht. Vor allem weil es auch in der frischen ioBroker-Installation auftrat. Es scheint auch unabhängig von den Adapterversionen zu sein, da es auch mit der ältesten und neusten Version auftrat.

Nun bleibt nur noch die Berechtigungsproblematik in der Adminoberfläche. Vielleicht hat hier jemand eine Idee.

[Thomas Braun]

@gifu

Immer noch die Empfehlung da NICHT /dev/ttyUSB0 sondern den by-id-Link zu verwenden.

[Gifu]

@thomas-braun
Ist doch nur von der Testinstallation...

[Thomas Braun]

@gifu

Und warum testest du mit ungünstigen Einstellungen?
Bringt dir für den 'Test' genau Null.

[Homoran]

hab diesen Thread leider zu spät gesehen, da ich zu den Themen (fast) nichts sagen könnte.
@Gifu
es wäre besser gewesen daraus 2-3 Threads mit dem jeweiligen Thema zu machen, damit man jeweils zusammenhängende Postings hätte.

@gifu sagte in Berechtigungsproblem Admin Panel und Zigbee Instabilität:

Ich kann in der ioBroker Adminoberfläche mit meinem Admin-Nutzer keine Objektzustände (true/false, Text) ändern.

hier hätte ich gefragt was das für DPs sind und wer due Rechte bestimmt hat.

deine Zusatzinfo

@gifu sagte in Berechtigungsproblem Admin Panel und Zigbee Instabilität:

    "role": "button",
    "read": false,
    "write": true

war schon richtig und wichtig, bringt mir aber kein Licht ins Dunkel

Wer lässt das lesen eines states nicht zu, aber das beschreiben?
leider ist dieser Datenpunkt
@gifu sagte in Berechtigungsproblem Admin Panel und Zigbee Instabilität:

"name": "Update Firmware",

nicht auf dem Screenshot zu sehen :-(

das müsste ein Taster sein.

Eine Auswirkung auf Blockly/NodeRed hat es nicht. Dort werden die Zustände sauber geschaltet.

weil die read/write Berechtigungen nur für die manuelle Einfabe gelten

[Gifu]

Hi @homoran,

wie eingangs geschrieben hatte ich gedacht, dass die beiden Probleme zusammenhängen. Zum Glück (oder Pech) ist dem nicht so.

Es sind tatsächlich alle Datenpunkte in der Adminoberfläche betroffen. Kein Datenpunkt kann von mir manuell geändert werden. Das Blockly einen anderen Nutzer verwendet (system), ist mir bewusst.

Die Rechte wurden nicht oder nicht bewusst verändert. Es trifft wie gesagt auf alle Datenpunkte zu. Mein Nutzer mit der Rolle admin darf es einfach nicht. Habt ihr Ideen?

[Homoran]

@gifu sagte in Berechtigungsproblem Admin Panel und Zigbee Instabilität:

Die Rechte wurden nicht oder nicht bewusst verändert.

auch (oder gerade) wenn es alle DPs betrifft, muss man doch irgendwo anfangen!

also nochmal:
was ist das für ein DP und wer/was hat ihn angelegt?

read=false und write=true ist in meinen Augen absoluter Blödsinn.

sieht es etwa bei allen DPs so aus?

[Gifu]

@homoran
Da hast du recht. An irgendeiner Ecke muss man anfangen. Ich würde direkt auf die neuen Objekte/Datenpunkte gehen, welche der Zigbee-Adapter angelegt hat. Das ist vielleicht etwas einfacher und wir stoßen nicht direkt auf irgendwelche Altlasten.

Beispiel:
Datenpunkt State. Wurde durch den Zigbee-Adapter angelegt.

Der Datenpunkt ist wie folgt definiert:

{
  "type": "state",
  "common": {
    "name": "On/off state of the switch",
    "type": "boolean",
    "read": true,
    "write": true,
    "role": "switch"
  },
  "native": {},
  "from": "system.adapter.zigbee.0",
  "user": "system.user.admin",
  "ts": 1659518748786,
  "_id": "zigbee.0.00124b0025e1f3e5.state",
  "acl": {
    "object": 1636,
    "state": 1636
  }
}

Wenn ich den Wert von false auf true ändern möchte, erscheint folgende Fehlermeldung.

Das Problem habe ich mit allen Datenpunkten. Egal, wie neu oder alt sie sind.

VG
Gifu

[Homoran]

@gifu sagte in Berechtigungsproblem Admin Panel und Zigbee Instabilität:

"type": "boolean",                                                                    

"type": "boolean",
"read": true,
"write": true,

Das sieht schon mal besser aus!

Der Timestamp ist auch aktuell, was ich jedoch nicht erkennen kann, welche Farbe false hat.
wird schwarz srin, da der Adapter ja schreiben darf.

Als welcher Ussr bist du im Admin?

wie sehen dessen Berechtigungen aus?

[Gifu]

@homoran
false ist schwarz. Mein Nutzer ist in der Admingruppe.

Der Standardnutzer von ioBroker "admin" kann diesen Datenpunkt state und andere Datenpunkte tatsächlich ändern... Jetzt verstehe ich gar nichts mehr. Das letzte Mal als ich das getestet habe, hat es auch mit dem Nutzer admin nicht funktioniert.

[Homoran]

@gifu sagte in Berechtigungsproblem Admin Panel und Zigbee Instabilität:

hat es auch mit dem Nutzer admin nicht funktioniert.

das wundert mich allerdings auch, da die Rechte in den Gruppen vergeben werden

dann wirf den User mal raus und füge ihn neu hinzu

welchen admin nutzst du?

[Gifu]

@homoran
Ich habe Admin v5.3.8. Meinen Nutzer habe ich gelöscht und neu angelegt. Das Verhalten hat sich nicht geändert. Die ACL für die Gruppe Admin sieht gut aus.

Gruppe Admin: