Behandlung von versteckten Räumen

Begonnen von Prof. Dr. Peter Henning, 30 Oktober 2018, 12:37:48

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Zur Erläuterung:

Das bisherige Verhalten von FHEMWEB war, dass Räume, die im Attribut "hiddenroom" als kommagetrennte Liste auftauchen,

a.) im normalen Raummenü nicht angezeigt wurden.
b.) per URL jederzeit als http://<ip-adresse:port>/fhem?room=<Raumname> erreichbar waren.

Rudi König hat eine Änderung durchgeführt, nach der Räume, die im Attribut "hiddenRoom" als kommagetrennte Liste auftauchen,

a.) im normalen Raummenü nicht angezeigt wurden.
b.) nicht mehr per URL erreichbar waren.

Das hatte negative Auswirkungen auf alle Nutzer der Module 95_Alarm.pm, 95_YAAHM.pm, 95_Babble.pm. Denn diese Module legen einen versteckten FHEM-Raum an, der nicht in dem normalen Raummenü auftaucht. Sondern - weil es sich um eine komplett andere Darstellung handelt - im oberen Menü auf der linken Seite per Link "Alarmanlage", "Profile" oder "Babble" erreichbar ist.

Diese Änderung wurde für den Moment zurückgenommen, soll aber nach Angabe von Rudi König wiederkommen.

Ich schlage hingegen vor, dass das ursprüngliche Verhalten beibehalten wird - denn "verstecken" ist nicht dasselbe wie "verbieten". Stattdessen soll FHEMWEB ein zusätzliches Attribut "forbiddenroom" bekommen, das ganz klar regelt, dass der betreffende Raum nicht erreichbar ist.

Sollte sich die Mehrheit dafür aussprechen, dass die Änderung ohne ein solches zusätzliches Attribut wieder eingeführt wird, werden die speziellen Räume für die obengenannten Module (also "Alarmanlage", "Profile" und "Babble") nicht mehr im oberen Menü angezeigt, sondern als ganz normale Räume behandelt werden.

LG

pah


rudolfkoenig

Meiner Ansicht nach sollte das programmatische Setzen von Attributen einer anderen Modulinstanz nicht ermutigt werden.
Vermutlich verstehe ich das Problem nicht, mir ist aber immer noch nicht klar, wieso man diese vom Benutzer definierte Instanzen nicht in der gewohnten Form presentieren kann, sondern eine eigene Loesung anbieten muss.

Prof. Dr. Peter Henning

Weil die "Räume" der Alarmanlage, von YAAHM und von Babble eine ganz andere Struktur aufweisen. Schau mal z.B. hier https://wiki.fhem.de/wiki/Modul_YAAHM

LG

pah

TL60

Auch mir ist noch ein Nebeneffekt durch die Veränderung bei der Behandlung versteckter Räume aufgefallen. Ich nutze das Homebridge-FHEM Modul des Users Justme (threat im Unterforum Sprachsteuerung) Verschiebe ich in der WEBtablet Instanz (Port:8085) den für die Definition des Homebridge-Plugins erforderlichen Raum Homekit in den Hiddenroom, so findet das Homebridge Plugin von FHEM keine Geräte mehr (Gerät antwortet nicht) das konnte ich durch mehrmaliges setzen bzw. Löschen des Attributes Hiddenroom reproduzieren. Erklären kann ich mir das Ganze nicht, da in der Config-Datei des Plugins explizit Port 8083 angesprochen wird:
"platforms": [
        {
            "platform": "FHEM",
            "name": "FHEMNetbook",
            "server": "127.0.0.1",
            "port": "8083",
            "filter": "room=Homekit"
        }, {

In der WEB Ansicht im Browser auf Port8083erscheint der Raum Homekit auch. Letztes FHEM update war von Samstag. Hat hier jemand von den Experten eine Erklärung, oder habe ich etwas falsch verstanden?

betateilchen

Das angestrebte Verhalten, die devices in hiddenroom nicht mehr per URL errreichbar zu machen, ist m.E. kompletter Unfug. Einerseits predigen wir, man soll alles über das Frontend machen, andererseits lassen wir devices auf Nimmerwiedersehen verschwinden?

Anwendungsbeispiel:

Bei Homematic devices, die mehrere Chennels besitzen, erfolgt die eigentliche Steuerung immer in den Channels, nicht im device. Deshalb habe ich alle Homematic devices in hiddenroom verschoben. In den Homematic Channels, die innerhalb von FHEM benutzt und dargestellt werden, habe ich in den Internals immer einen Link zum zugehörigen HM-device selbst und kann dieses bei Bedarf direkt aufrufen.

Wie soll ich künftig auf kürzestem Weg im FHEM Frontend zu diesen devices gelangen? Die Einführung eines zusätzlichen Attributes ist für mich keine Option.

Wurde der hiddenroom nicht explizit dafür geschaffen, devices NUR aus der Anzeige zu entfernen und nicht dafür, diese devices komplett unerreichbar zu machen?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Die Detailansicht der Geraete ist weiterhin erreichbar.
Nur der Raum an sich kann nicht auf dem erwaehnten FHEMWEB-Instanz angezeigt werden.
ZitatIn den Homematic Channels, die innerhalb von FHEM benutzt und dargestellt werden, habe ich in den Internals immer einen Link zum zugehörigen HM-device selbst und kann dieses bei Bedarf direkt aufrufen
Ich gehe davon aus, dass das weiterhin funktioniert.
Geraete kann man einfacher verstecken, indem man diesen room hidden zuweist. Dann muss man nicht zusaetzlich auch noch bei jeder FHEMWEB Instanz hiddenroom pflegen.

betateilchen

Zitat von: rudolfkoenig am 31 Oktober 2018, 11:57:06
Nur der Raum an sich kann nicht auf dem erwaehnten FHEMWEB-Instanz angezeigt werden.

Was wäre der tatsächliche Nutzen dieser Änderung? Ich erkenne bis jetzt auschließlich Nachteile.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

marvin78

Offensichtlich gibt es Leute, die ihren Mitbewohnern nicht trauen, ihnen böse Dinge zutrauen oder sonstiges. Man möchte ihnen verbieten, einen Raum per URL aufrufen zu können. Das alles wird unter dem Mantel des Sicherheitsaspektes gewünscht. Das kann man sinnvoll finden oder nicht. Ich halte es für überflüssig.

Prof. Dr. Peter Henning

Darum ja mein Vorschlag: hiddenroom wird wie bisher behandelt. Wer wirklich einen Raum unerreichbar machen möchte, sollte diesen Raum in das neue Attribut forbiddenroom aufnehmen.

Bei HomeMatic habe ich das übrigens genauso realisiert wie betateilchen

Zum verbotenen Raum:

Meiner Katze möchte ich den Raum verbieten, in dem ich das Device für den Katzenfutterautomaten aufgestellt habe. Nur so als Beispiel ...

LG


rudolfkoenig

ZitatOffensichtlich gibt es Leute, die ihren Mitbewohnern nicht trauen, ihnen böse Dinge zutrauen oder sonstiges.
In manchen Faellen wird FHEM fuer die Steuerung der Einrichtungen einer Turnhalle, Gemeinde- oder Vereinsraum verwendet.
Dass man da nicht jedem alles erlauben will, liegt auf der Hand.

Ich habe bisher verstanden, dass man hiddenroom in einer Art verwendet hat, die ich nicht beabsichtigt habe. Ich habe aber noch nicht verstanden, ob das eine Notwendigkeit fuer bestimmte Aufgaben ist, oder nur ein "ich wusste es nicht besser".

Prof. Dr. Peter Henning

Na ja. Das ist kein "Ich wusste es nicht besser" - sondern ein "Ach, so geht es ja".

Und, wie gesagt: "verstecken" ist nicht gleich "verbieten". Das erste kann durchaus ergonomische Gründe haben (Siehe Post von Udo), das zweite kann Sicherheitsgründe haben. Beides hat m.E. seine Berechtigung, ist aber nicht deckungsgleich.

LG

pah

betateilchen

Zitat von: rudolfkoenig am 31 Oktober 2018, 14:37:09
Ich habe bisher verstanden, dass man hiddenroom in einer Art verwendet hat, die ich nicht beabsichtigt habe.

Naja, Du hast ein Feature geschaffen, das bestimmte Möglichkeiten bietet, an die Du einfach im Vorfeld nicht gedacht hattest. Trotzdem wird das bestehende Feature offenbar gerne in genau dem bisher vorhandenen Umfang wertgeschätzt und genutzt.

Wenn es nun offenbar eine (neu hinzugekommene) Anforderung gibt, die das "verbieten" verfügbar machen soll, sollte man überlegen, das auch als neue/zusätzliche Funktionalität zu schaffen. Um Verwirrungen zu vermeiden, sollte dieses neue Feature möglichst namentlich nichts mit hiddenRoom beinhalten. Wie wäre es beispielsweise mit "forbiddenRoom" ?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Nach soviel "sanften" Ueberredung habe ich forbiddenroom eingebaut, ist (bis auf die Raumanzeige per URL) identisch mit hiddenroom.

Uebrigens: "hiddenroom detail" versteckt nicht nur den Link, sondern untersagt auch die Anzeige von Detailseiten.
Das bleibt aber so, wer weiss, wer sich schon seit 4 Jahren darauf verlaesst, und meinen Kopf abreisst, wenn ich es fixe.

Prof. Dr. Peter Henning

Rudi, das war doch wirklich sanft - und Du bekommst einen Extrapreis für Demokratie. Danke.

Und wenn Dir deswegen jemand den Kopf abreißen will, sag ihm, Du würdest es mir petzen.


LG

pah

duke-f

Bin ja etwas spät auf die Thematik gestoßen, will aber im Nachhinein doch meine Zustimmung der Trennung von "forbidden" und "hidden" geben.

Ich habe Räume aus reinen Performance-Gründen versteckt, die kein Mitbewohner nutzen muss. Ich selber weiß aber immer den Weg dahin - beispilesweise ganz einfach in einem Raum, in dem eine bestimmte Device steht (bei mir der Drucker im sichtbaren Raum "Keller"), gehe in der Ansicht des "Druckers" nach unten zu den Attributen und habe da bei Räumen zusätzlich "EDV" (altes Wort für IT  :P ) um in den Raum mit allen computerspezifischen Devices zu kommen. Nutzt mir beispielsweise bei WebViewControl, das ja nicht über eine Eingabemöglichkeit in Form einer Adresszeile verfügt. Ich vermute, dieser Weg wäre mir auch versperrt worden mit der alten/neuen Variante.
Cubietruck, 3 Raspberry Pis,
CUL868, RFXtrx433, CUL433, SCC868, HM-USB,
IRTrans, EZcontrol XS1, IguanaWorks USB IR Transceiver
ESPEasy, Fritz!Box, Samsung TV+BD, LMS, Squeezelite

JensS

#15
Danke für forbiddenroom. Damit ist mein FHEM intern sicherer. Würde auch ein forbiddendeviceRegexp möglich sein, bei dem man den Zugriff alle Devices, welche einem bestimmten Raum zugeordnet sind, unterbindet?

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.