Lässt sich "setuuid" deaktivieren oder ignorieren

Begonnen von cocojambo, 23 Januar 2019, 13:19:05

Vorheriges Thema - Nächstes Thema

Beta-User

Vorab: sorry, wenn ich das mißverstanden hatte.

Schade, wenn meine Anmerkungen als negative Stimmungsmache ankamen, das war nicht beabsichtigt, und das hast du auch nicht verdient!

(Ich verstehe allerdings nach wie vor nicht so ganz, wieso du dann den "legalen Weg" besser beschrieben haben willst, das leuchtet mir einfach nicht ein).

Zitat von: frank am 27 Februar 2019, 16:57:39
wenn beim einlesen der fhem.cfg, genau so wie über FHEMWEB, fehlerhafte anweisungen (define, attr) nicht zur ausführung kommen und identische fehlermeldungen im log erscheinen, verstehe ich die ganze aufregung um das editieren schon gar nicht mehr. dann sollte fhem doch weiterhin funktionieren, allerdings ohne die fehlerhaften anweisungen.
Das ist nach meinem Kenntnisstand in der Regel auch so, dass FHEM - dann halt ggf. ohne die "kaputten Defines" startet und ins log schreibt, was übergangen wurde.

Warum also die "Aufregung" und die nachdrückliche Empfehlung, die editierer-Variante nicht zu propagieren:
Beim direkten Editieren kann man - aufgrund welcher Ursachen auch immer - allerdings mehr durcheinanderbringen als von FHEMWEB aus, beispielsweise die nachfolgende Zeile versehentlich maskieren, oder ein Hochkomma alleine stellen....
Als "Soweiso-Linuxer" habe ich da keine Erfahrung, aber "falsche" Zeilenumbrüche aus Redmond sind wohl auch was, auf das man aufpassen muß.
Aber im Ernst: Ich würde mir nicht zutrauen, eine "Wie editiert man fhem.cfg unfallfrei"-Anleitung zu schreiben. Die Erfahrung lehrt: irgendwas anderes, als das, was man geschrieben hat, geht dann doch schief, und hinterher beschwert sich der Betroffene, warum man das vergessen hat, wäre doch wichtig gewesen...

Wie dem auch sei, ich helfe auch weiterhin auch cfg-Editierern ;) . Anfänger bekommen halt den Schubser Richtung "stressfreier" Variante, und wer dann nicht ins log sieht, bekommt schließlich keinen support mehr. Die Erfahreneren haben sowieso entweder keine einfach zu beantwortenden Fragen und genug Erfahrung. Die Freiheit gönne ich ihnen, Verbote müssen nicht sein.

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

marvin78

Und wieder dreht es sich im Kreis. Es gibt weder eine Hexenjagd noch negative Stimmungsmache. Es gibt lediglich Leute, die besseres zu tun haben, als Leuten zu helfen, die Beratungsresistent sind. Und das ist fair und gut. Wer es anders will, kann Pech haben. Auch gut.

gloob

Tut euch allen doch bitte einen gefallen und schließt den Thread hier, dass führt doch zu nichts sinnvollem.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

PeMue

Ok, gerade über die Suche gefunden. Sie setuuids sind für die Weiterentwicklung da und müssen mich nicht weiter stören. Alles andere - naja - da mische ich mich lieber nicht ein. Und: wofür die Dinger da sind, wurde nicht wirklich gesagt ...

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

justme1968

wegen der suche:

Zitat von: PeMue am 03 September 2019, 20:17:18Und: wofür die Dinger da sind, wurde nicht wirklich gesagt ...

doch. wurde es. mehrfach. unter anderem im ursprungs thread hier: https://forum.fhem.de/index.php/topic,95902.msg888387.html#msg888387 und im weigern verlauf des threads gibt es noch mehr beispiele.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

PeMue

Zitat von: justme1968 am 03 September 2019, 20:33:40
wegen der suche:

unter anderem im ursprungs thread hier: https://forum.fhem.de/index.php/topic,95902.msg888387.html#msg888387 und im weiteren verlauf des threads gibt es noch mehr beispiele.
Ok, danke. Dann habe ich diesen nicht gefunden. Vermutlich weil ich die Suche nach dem ersten (vermeintlich besten) Treffer abgebrochen habe. Danke.

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

christiantf

Ich kann nachvollziehen, dass es eine eindeutige ID braucht.

Aber wie genau gebt ihr Ausschnitte aus der Config an andere weiter?
Macht ihr einen Screenshot oder nehmt ihr nicht doch eher ein Copy/Paste aus der fhem.cfg?
Kopiert ihr dabei die ID mit?
Oder löscht ihr sie raus?

Bezüglich Config bearbeiten:
Ist eh nett gemeint, dass fhem.cfg bearbeiten "verboten" sein soll. Aber es gibt halt nix anderes, was irgendwie übersichtlich ist. Oder wie wäre der Weg, größere Teile einer Config von einem System zum anderen zu transportieren?
Oben in der Commandline definiere ich sicher keine MQTT Topic Attribute für eine Menge Devices, und dieses RAW Fenster, was genau soll das gut sein? Da seh ich auch nichts von der bestehenden Config, oder kann nichts Bestehendes bearbeiten.

Und dass man die fhem.cfg nicht bearbeiten dürfen soll, es aber gar keine andere, gleichwertige Alternative gibt, finde ich dann doch sehr strange.

Jedenfalls ist es nervig, wenn man z.B. Samples aus dem Web zum Testen in die fhem.cfg übernimmt und dann nichts funktioniert. Weil die uuid fehlt. Wenn diese schon übers WebUI automatisch angelegt wird, dann könnte sie genauso gut beim Speichern der fhem.cfg im WebUI automatisch angelegt werden.

Die Syntax von FHEM ist nunmal nicht für Herumgeklickse ausgelegt, sondern für einen Editor.

amenomade

#97
Zitat von: christiantf am 27 November 2019, 23:52:32
Aber wie genau gebt ihr Ausschnitte aus der Config an andere weiter?
Ich klicke auf "Raw definition" des gewünschten Device, und mache ein Copy/Paste. Die UUID ist da nicht sichtbar

ZitatDa seh ich auch nichts von der bestehenden Config, oder kann nichts Bestehendes bearbeiten.
Doch sieht man die vollstäntige Definition eines Devices. Man kann auch alles ändern, und man kann auch alles löschen, und ein Code Snipet einfügen (und die UUID wird automatisch kreiert). Sogar mit Syntax Highlighting (codemirror) und Syntax-Kontrolle

Seit 1,5 Jahre habe ich meine fhem.cfg nie editiert, weder auf dem produktiven System (ist sowieso auf ConfigDB) noch auf meinen beiden Testsystemen (noch mit fhem.cfg Dateien). Und ich bin fast sicher, dass ich viel mehr rumspiele als Du.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

christiantf

Du hast absolut Recht  ::) Ich dachte irgendwie, das "Plus" links neben der Commandline wäre die "Raw definition". Und das kommt auch nur, wenn ein Device schon existiert.
In FHEM bzw. der FHEM-Config bin nur ab und zu, praktisch nie, und in der Regel nur dann, wenn etwas nicht mehr funktioniert oder ich was für jemanden ausprobieren.

Ich komme aus einer anderen Smarthome-Welt - KNX, Home Assistant, Loxone.

Auf die Gefahr hin, dass ich "der unwissende DAU" bin, möchte ich trotzdem hier meinen Blickwinkel zur ganzen Editor-Geschichte darlegen:

- "Raw definition", also ein Pseudo-Editor, warum wird das nur bei bestehenden Devices angezeigt, aber nicht immer? Das Konzept ohne fhem.cfg Editor, aber mit einem Pseudo-Texteditor, ist überhaupt nicht durchgängig. Da ist oben eine Command line, daneben ein Plus, dann mal ein "Raw definiton" klein irgendwo unten in der Fusszeile.

- Der eigentliche Attribut-Editor im WebIf, um Einstellungen festzulegen und zu ändern, ist viel zu viel Herumgeklickse um etwas einzustellen: Ein Dropdown öffnen, in der Attributliste herumsuchen, einen Eintrag auswählen, rechts einen Wert hinschreiben und dann links(!?) klicken, um den Wert zu setzen. Danach habe ich EIN Attribut gesetzt...!

- Warum werden bei einem Device nicht einfach alle Attribute als Liste hingeschrieben, rechts jeweils ein Eingabefeld und rechts daneben ein "Speichern-Symbol". Mit Tab von Feld zu Feld springen, und unten zusätzlich ein "Alles speichern". SO gibt man schnell Werte ein, und behält die Übersicht, was man gerade konfiguriert.

- So Dinge wie room oder group gehören immer oben hin, das sind für ein Smart Home doch die wichtigsten Eigenschaften...!

- Wie legt man ein neues Device über den Attribut Editor an? Alle Typen sind bekannt, es wäre doch sinnvoll, das ich ein Gerät mit einer Typ-Auswahl anlegen kann, statt einen String aus der Command Reference in die Eingabezeile zu kopieren.

- Das Datenmodell der configDB hab ich mir im Sourcecode angesehen, und das ist ja einfach eine 1:1 Kopie der fhem.cfg. Das Datenmodell gibt nichts her, außer dann man jetzt eine Volltextsuche machen kann. Da sehe ich für die Software jetzt noch gar keinen Vorteil, wenn die Datenbank noch nicht mal nach Type eines Devices unterscheiden kann.

Ich weiß, "das war immer so", "das gehört so", "du kennst dich nicht aus" usw. Stimmt alles. Das macht das Feedback vielleicht gerade erst interessant ;-)

lg, Christian

PS: Bitte schimpft nicht über Leute, die nicht jede Änderung am Sourcecode mitverfolgen, sondern die Software einfach benutzen, und dann mal eine Frage stellen. Das mit dem "Nicht die fhem.cfg bearbeiten" habe ich beispielsweise noch nie irgendwo gelesen.

amenomade

ZitatUnd das kommt auch nur, wenn ein Device schon existiert.
Ich kenne kein Fhem, der kein Device hat... Schon um eine Weboberfläsche zu haben, gibt es ein Device des Typs FHEMWEB und ein Device global

Zitat- Der eigentliche Attribut-Editor im WebIf, um Einstellungen festzulegen und zu ändern, ist viel zu viel Herumgeklickse um etwas einzustellen: Ein Dropdown öffnen, in der Attributliste herumsuchen, einen Eintrag auswählen, rechts einen Wert hinschreiben und dann links(!?) klicken, um den Wert zu setzen. Danach habe ich EIN Attribut gesetzt...!

- Warum werden bei einem Device nicht einfach alle Attribute als Liste hingeschrieben, rechts jeweils ein Eingabefeld und rechts daneben ein "Speichern-Symbol". Mit Tab von Feld zu Feld springen, und unten zusätzlich ein "Alles speichern". SO gibt man schnell Werte ein, und behält die Übersicht, was man gerade konfiguriert.
Es gibt auch Devices, die über 100 mögliche Attribute haben (für HTTPMOD sogar unendlich - hab eins mit 300 Attribute). Schon ein HM Rollo mit ASC hat um die 100 Attribute. Wäre sehr unübersichlich, alle immer am Bildschirm zu haben, wenn nur eine 10 davon benutzt sind.

Zitat- So Dinge wie room oder group gehören immer oben hin, das sind für ein Smart Home doch die wichtigsten Eigenschaften...!

- Wie legt man ein neues Device über den Attribut Editor an? Alle Typen sind bekannt, es wäre doch sinnvoll, das ich ein Gerät mit einer Typ-Auswahl anlegen kann, statt einen String aus der Command Reference in die Eingabezeile zu kopieren.
Interessant

Zitat- Das Datenmodell der configDB hab ich mir im Sourcecode angesehen, und das ist ja einfach eine 1:1 Kopie der fhem.cfg. Das Datenmodell gibt nichts her, außer dann man jetzt eine Volltextsuche machen kann. Da sehe ich für die Software jetzt noch gar keinen Vorteil, wenn die Datenbank noch nicht mal nach Type eines Devices unterscheiden kann.
Nicht 1:1. ConfigDB hat Versioning dazu
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

CoolTux

Zitat von: christiantf am 28 November 2019, 01:29:39
- "Raw definition", also ein Pseudo-Editor, warum wird das nur bei bestehenden Devices angezeigt, aber nicht immer? Das Konzept ohne fhem.cfg Editor, aber mit einem Pseudo-Texteditor, ist überhaupt nicht durchgängig. Da ist oben eine Command line, daneben ein Plus, dann mal ein "Raw definiton" klein irgendwo unten in der Fusszeile.

- Der eigentliche Attribut-Editor im WebIf, um Einstellungen festzulegen und zu ändern, ist viel zu viel Herumgeklickse um etwas einzustellen: Ein Dropdown öffnen, in der Attributliste herumsuchen, einen Eintrag auswählen, rechts einen Wert hinschreiben und dann links(!?) klicken, um den Wert zu setzen. Danach habe ich EIN Attribut gesetzt...!

- Warum werden bei einem Device nicht einfach alle Attribute als Liste hingeschrieben, rechts jeweils ein Eingabefeld und rechts daneben ein "Speichern-Symbol". Mit Tab von Feld zu Feld springen, und unten zusätzlich ein "Alles speichern". SO gibt man schnell Werte ein, und behält die Übersicht, was man gerade konfiguriert.
Gueten Morgen,

Weil jemand sich hingesetzt hat und in seiner Freizeit es so programmiert hat. Man kann es auch anders machen wenn es einem nicht zu sagt. Hier ist nichts in Stein gemeißelt. Du kannst DEIN Frontend so machen wie Du es für Gut und Richtig erachtest.

Zitat von: christiantf am 28 November 2019, 01:29:39
- So Dinge wie room oder group gehören immer oben hin, das sind für ein Smart Home doch die wichtigsten Eigenschaften...!
Wer sagt sowas! Steht das irgendwo in einer Guidline oder so?
6 User die ich kenne und ich interessiert es zum Beispiel gar nicht wo was im FHEMWEB steht, wir benutzen es nicht. Du siehst, Deine Aussagen mögen für Dich zutreffend sein. Für andere sicherlich nicht. Wenn Du ein Frontend für FHEM Entwickeln möchtest dann findest Du aber auch sicherlich 1000 Leute die, sofern Du es nach deren Geschmack machst, Dir Zustimmung geben und sagen ja so sollte es aussehen das finde ich toll. Bis dahin kann man zwar sagen das man es selbst ungünstig im Aufbau findet aber mehr bitte auch nicht.


Zitat von: christiantf am 28 November 2019, 01:29:39
- Das Datenmodell der configDB hab ich mir im Sourcecode angesehen, und das ist ja einfach eine 1:1 Kopie der fhem.cfg. Das Datenmodell gibt nichts her, außer dann man jetzt eine Volltextsuche machen kann. Da sehe ich für die Software jetzt noch gar keinen Vorteil, wenn die Datenbank noch nicht mal nach Type eines Devices unterscheiden kann.
Wozu soll die Datenbank nach Device Typen unterscheiden können. Sowas ist nicht Teil einer Datenbank. Eine Datenbank hat Daten vor zu halten und gut ist. Derjenige der den Aufbau der Datenbank plant kann entscheiden was wie benötigt wird. Wenn derjenige sagt es ist nicht wichtig weil man es ja über FHEM macht dann ist es eben so.

Ich kenne persönlich Deine FHEM Erfahrung nicht, aber ich würde mal sagen versuche doch erstmal FHEM kennen zu lernen, schaue wie Du was an Logik und Geräten unterbringst und schaue Dich um ob Du nicht noch ein anderes für Dich besser passendes Frontend findest. FHEMWEB ist nicht das einzige.


Grüße
Leon
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

amenomade

Trotzdem finde ich folgendes interessant:
ZitatAlle Typen sind bekannt, es wäre doch sinnvoll, das ich ein Gerät mit einer Typ-Auswahl anlegen kann, statt einen String aus der Command Reference in die Eingabezeile zu kopieren.
im Sinn von "Unterstützte Erstellung eines Devices"
Mir fehlen die Programmierungkenntnisse (Hmmm... stimmt nicht ganz... eigentlich fehlt mir eher die Zeit...), um sowas zu programmieren, aber ich sehe das als Verbessrungsvorschlag...

Und... algemeines Kommentar: man muss nicht unbedingt jeden Kommentar interpretieren, als ob etwas "falsch" entwickelt gewesen wäre. Natürlich kann jeder sein Frontend entwickeln. Das heisst nicht, dass das Hauptfrontend nicht verbessert werden kann. ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

justme1968

und warum ist es einfacher aus einer liste von 500+ typen auszuwählen statt eine hand voll buchstaben zu tippen?

eine scheinbar endlose liste ist keine lösung.

devices automatisch suchen und anlegen ist ein teil der lösung. leider komme ich nicht dazu damit eiter zu machen. wie so etwas aussehen könnte ist hier: https://forum.fhem.de/index.php/topic,67368.msg880001.html#msg880001 zu sehen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

amenomade

Zitat von: justme1968 am 28 November 2019, 12:02:24
und warum ist es einfacher aus einer liste von 500+ typen auszuwählen statt eine hand voll buchstaben zu tippen?
eine scheinbar endlose liste ist keine lösung.
Da hast Du natürlich recht.

Zitat von: justme1968 am 28 November 2019, 12:02:24
devices automatisch suchen und anlegen ist ein teil der lösung. leider komme ich nicht dazu damit eiter zu machen. wie so etwas aussehen könnte ist hier: https://forum.fhem.de/index.php/topic,67368.msg880001.html#msg880001 zu sehen.
Ich fand das sehr verspreschend, als ich es gelesen habe. Warum schaffst Du es nicht weiter zu machen? Zeit (kann ich verstehen)?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

MadMax-FHEM

Klingt für mich auch ein wenig nach attrTemplate!?

Da wählt man doch bei einem "pseudo angelegten" Device dann den richtigen (hoffentlich ;) ) Typ aus bzw. macht eine "Feinspezifizierung"!?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)