[erledigt] SVG problem: gplot file marked as readonly: won't write!

Begonnen von the ratman, 18 Mai 2022, 11:58:26

Vorheriges Thema - Nächstes Thema

the ratman

hiho,

nach längerer zeit, wollt ich wieder mal einen plot anlegen, also:
"define plot_spritpreise SVG logdb:plot_spritpreise:HISTORY"

das svg wird angelegt, ich kann aber im svg (außer bei den attributes) nirgendwo was eintragen und drücke ich auf "write .gplot" schreibt er die freundliche meldung aus der überschrift raus.

o) das gplot-verzeichnis hab ich mittlerweile auf 777, mit dem user "fhem" als eigentümer
o) drücke ich bei einem vorhandenen plot auf "write .gplot" macht er dies anstandslos

hat sich irgendwas verändert, dass ich verpennt hab, oder was rennt hier falsch?
→do↑p!dnʇs↓shit←

MadMax-FHEM

#1
https://forum.fhem.de/index.php/topic,126561.msg1211685.html#msg1211685

EDIT:
Zitat
o) das gplot-verzeichnis hab ich mittlerweile auf 777, mit dem user "fhem" als eigentümer
warum immer gleich Rechte aufbohren ;)

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)

the ratman

einfach nur zur sicherheit beim testen. nicht, dass es an den rechten scheitert *g*

danke dir für den hinweis - jetzt geht's.

anm.:
wie ich das hasse, wenn man mal 5 min in fhem nicht aufpasst und irgendwer irgendwas verdreht.
manches mal hab ich den eindruck, dass machen die leuts nur, um die noobs zu ärgern *g*
→do↑p!dnʇs↓shit←

rudolfkoenig

Zitatwie ich das hasse, wenn man mal 5 min in fhem nicht aufpasst und irgendwer irgendwas verdreht.
Und ich frage mich, warum die Leute dauernd FHEM-updates machen, wenn sie keine Aenderungen wollen. :)

the ratman

#4
ich hab nix gegen änderungen, nur probleme, wenn ich nix von weiß und dann wie n dödel da stehe.

frage:

irgendwie wärs wohl mal überlegenswert, wenn man eine "update" info in fhem hätte.
könnte man das nicht automatisiert aus eurem "code changes" entnehmen? z.b. in ein modul.
vielleicht sogar einstellbar mit: "noob-infos", "fortgeschrittenes", oder alle updates für "coder" ...

noob-info: "knöpfchen x macht jetzt y". oder: "da ist eine neue funktion für dich hinzugekommen".
internes gedöns interessiert leute wie mich eh ned, weil wirs sowieso ned verstehen ...

könnte ich mir so richtig schön vorstellen. du machst 'n update, schaust dann in dein logfile, ob eh alles gut gegangen ist und dort steht dann das wichtigste an änderungen für deine module.
oder die "noob-proof" version: nach n update steht ein popup für den dümmsten da, bis man o.k. klickt *g*
→do↑p!dnʇs↓shit←

frank

Zitatich hab nix gegen änderungen, nur probleme, wenn ich nix von weiß und dann wie n dödel da stehe.
was ist mit "update check" vor einem update?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

ich hab ja kein update-problem gehabt, nur ein info-problem.
was nutzt mir auch ein update-check, wenn die änderung schon 1 monat her und eigentlich ja nicht mal ein fehler ist?

wirfst du dann prof. dr. dr. google an, findest du auch wunderschöne infos zur fehlermeldung. leider nix richtiges, weil du da meist über infos zu user/file-rechte stolperst.
ohne MadMax-FHEM's link würd ich wahrscheinlich jetzt noch nach dem problem suchen.

obige "idee" würde großteils vermeiden.
→do↑p!dnʇs↓shit←

Beta-User

...irgendwie ist diese Diskussion um "wie als User Info über updates im Voraus erhalten" ein Dauerbrenner...

Habe z.B. das hier gefunden (2012): https://forum.fhem.de/index.php/topic,9085.0.html, aber eigentlich gesucht nach was, wo es fast wortgleich auch Hinweise zu "inform" (?) gab...

Kurzfassung aller Diskussionen, die ich dazu kenne: Die Maintainer müßten was kompliziertes pflegen, und die User müßten das dann auch lesen. Vermutlich ist in CHANGED der erste Teil sogar meistens (!) noch gut abgedeckt, wenn auch in vereinfachter Form...

Vielleicht wäre die Summe der Änderungen seit 6.1 ausreichend, um 6.2 zu "veröffentlichen"? (V.a. in Homematic-Bereich (alle Module) scheint es soweit ruhig zu sein...). Dann hat der updategeeigte User zumindest einen "Anhaltpunkt", dass er sich mal umsieht, was ggf. passiert ist ::) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

the ratman

tjo, der user ists halt gewohnt, seine infos in schönen, verständlichen häppchen zu kriegen, oder a'la google-android "wir haben etwas verbessert, um ihr nutzererlebnis weiter zu trüben" *g*

aber im ernst - eigentlich stünde ja schon alles hier im forum in den "code changes"
das müsste ja "nur" gefiltert werden, weil alles eh keiner lesen und verstehen würde ... also ich.

ich weiß, ich hab leicht reden .. aber ihr habt's immer gute ideen. ich wart mal ab, dann schleicht sich sicher wieder irgend ne geile lösung von euch durchs hintertürchen.
→do↑p!dnʇs↓shit←

Beta-User

Zitat von: the ratman am 18 Mai 2022, 14:16:37
das müsste ja "nur" gefiltert werden, weil alles eh keiner lesen und verstehen würde ... also ich.
Na ja, die "messages", die der jeweilige Maintainer beim Einchecken von Änderungen mitgibt, sind mal mehr, mal weniger aufschlussreich, und wie "gefährlich" was ist, kann man m.E. nicht mit vertretbarem Aufwand automatisiert ermitteln (zumal das ggf. auch noch subjektiv (aus Usersicht ) gefärbt ist).
Also gibt es keinen wirklich besseren Weg, als diese Verantwortung dem jeweiligen Maintainer zu übergeben - und der schreibt halt ggf. was in CHANGED (bzw. UPGRADE) rein, oder eben nicht. (oder - so entsprechende Optionen vorhanden wären - er würde bestimmte "flags" beim Einckecken setzen oder eben nicht...)

Zitat
ich weiß, ich hab leicht reden .. aber ihr habt's immer gute ideen. ich wart mal ab, dann schleicht sich sicher wieder irgend ne geile lösung von euch durchs hintertürchen.
Wie angedeutet ist das die vergangenen 10 Jahre (+?) immer wieder ein Thema gewesen, und ich glaube ehrlich gesagt nicht, dass da jemand "plötzlich" eine zündende bessere Idee hat. Wenn, dann müßte "jemand" im Nachgang zu irgendwelchen Änderungen einen review machen und festlegen, ob die jeweilige Änderung (bzw. ein Entwicklungsschritt, der mehrere umfasst) "bekannt" gemacht werden sollten (oder sonstwie klassifiziert). Das ist aber eine Heidenarbeit und mit subjektiven Elementen gespickt. Nun ja, ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

the ratman

versteh's eh. aber man muss euch ja auch ein bissi fordern, sonst wird euch ja noch langweilig *g*
ein argument hab ich für die maintainer aber: je besser der dau geführt wird, je weniger nervt er.
→do↑p!dnʇs↓shit←

Beta-User

Zitat von: the ratman am 18 Mai 2022, 14:43:24
ein argument hab ich für die maintainer aber: je besser der dau geführt wird, je weniger nervt er.
Aha...

Mein Eindruck ist eher: Je besser er geführt ist, desto weniger denkt er selbst nach, und desto seltsamere Dinge passieren...

(Die hier diskutierte Änderung ist jedenfalls mAn. sehr sinnvoll gewesen, weil sie versehentliche Manipulationen an den zentral verteilten .gplot verhindert und daher eher alle auf einem Stand sind...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

the ratman

ich zweifle auch nicht an sinnhaftigkeiten. dafür haben wir euch ja, damit fhem immer sinnvoller wird ...

ich zweifle (denke, da haben sogar wir 2 schon mal geredet drüber), an der grundlegenden kommunikation zwischen programmierer und anwender. der ein fühlt sich angegriffen, weil der andere nicht versteht was gemeint ist. keiner meints böse, aber ... und da für eine schnittstelle zu sorgen wäre traumhaft.
→do↑p!dnʇs↓shit←